HAIAMM v3.0, Endpoints Domain Handbook

AI/HAI Endpoint Assurance, security of the AI/HAI-enabled endpoints and user-facing AI interfaces the organization deploys, manages, or governs

Version: 3.0 Domain: Endpoints Audience: Security, IT / Endpoint Management, Workplace Technology, Engineering and Product, Privacy/Legal, HR Use: Conduct a maturity assessment of the AI/HAI Endpoint Assurance program, and build the practices that move it from Foundational to Industry-Leading.

Preface

This handbook is a self-contained, practitioner-facing document. Read it end to end to understand the Endpoints domain of HAIAMM, or jump to Part IV to perform an assessment.

The handbook makes three commitments to the reader:

1. Fundamentals first. It teaches the load-bearing practices an organization must have to claim mastery of the security of its AI/HAI-enabled endpoints and user-facing AI interfaces, not a catalog of everything one could do.
2. Measurable by default. Every activity prescribed in these pages is paired with at least one outcome metric (with a baseline, a target, and a source). Activity counts are not metrics; outcomes are.
3. Self-contained. The document does not require the reader to follow links, open companion files, or chase references. Every concept used in the assessment is defined inside these pages.

If a statement in this handbook treats AI as a tool performing endpoint security rather than the AI-enabled endpoint as the subject being secured, that statement is wrong. Flag it.

Table of Contents

Part I, Domain Overview

1. About this handbook
2. The Endpoints domain in v3.0 terms
3. Why a domain-specific handbook
4. The seven AI/HAI endpoint archetypes
5. Domain boundary rules
6. Stakeholders and roles
7. How to use this handbook

Part II, Foundations

1. The four Business Functions in this domain
2. The three maturity levels
3. HAI-specific threat tactics (EA, AGH, TM, RA)
4. The priority compliance map
5. Shadow AI in the Endpoints domain (ungoverned AI on endpoints)
6. Metrics taxonomy

Part III, The Twelve Practices in the Endpoints Domain

1. Strategy & Metrics (SM)
2. Policy & Compliance (PC)
3. Education & Guidance (EG)
4. Threat Assessment (TA)
5. Security Requirements (SR)
6. Secure Architecture (SA)
7. Design Review (DR)
8. Implementation Review (IR)
9. Security Testing (ST)
10. Environment Hardening (EH)
11. Issue Management (IM)
12. Monitoring & Logging (ML)

Part IV, Maturity Assessment Workbook

1. How the assessment works
2. Scoring methodology
3. The questionnaire (108 questions)
4. Practice-level rollup
5. Domain-level rollup
6. Improvement roadmap template

Part V, Reference

1. Glossary
2. Reference frameworks
3. Change log

Part I, Domain Overview

1. About this handbook

HAIAMM is the Human-Assisted Intelligence Assurance Maturity Model. It is an AI assurance maturity model, structured after OWASP SAMM and BSIMM in shape, and scoped to AI/HAI in content. HAIAMM has six domains, Software, Data, Endpoints, Infrastructure, Vendors, Processes, and twelve practices that apply across all six.

This handbook covers the Endpoints domain. It contains:

• A definition of what the Endpoints domain is and is not.
• The twelve practices, each described in Endpoints-domain terms with three maturity levels (Foundational, Comprehensive, Industry-Leading).
• A complete maturity assessment workbook with 108 yes/no questions and a scoring methodology.
• A reference section with a glossary and the major frameworks HAIAMM aligns with.

This is one of six domain handbooks. Endpoints-specific assessment questions live only in this handbook; the Software handbook contains only Software questions, the Data handbook only Data questions, and so on.

2. The Endpoints domain in v3.0 terms

The Endpoints domain governs the AI/HAI-enabled endpoints and user-facing AI interfaces the organization deploys, manages, or governs, the AI surfaces that reach employees and customers through their devices, browsers, mobile apps, and edge hardware. The organization deploys these surfaces itself (own-built chatbots, mobile AI apps, edge AI devices) or governs the consumption of vendor-provided surfaces on managed endpoints (AI assistants, browser extensions, SaaS-AI productivity features).

In scope:

• AI assistants and copilots on managed endpoints, Cursor, GitHub Copilot, Claude Code, internal AI assistants on engineering laptops, AI productivity assistants accessed from work endpoints.
• Browser-based AI tools, web AI interfaces, AI browser extensions (Grammarly AI, page summarizers, screenshot tools), browser-launched AI experiences.
• Chatbots and conversational UIs, own-built customer-facing chatbots, employee-facing conversational interfaces, AI-augmented support chat.
• Multi-modal AI interfaces, voice, image, video AI surfaces on endpoints, including AI-enabled accessibility surfaces.
• AI-augmented productivity (SaaS-AI on endpoints), M365 Copilot, Slack AI, Notion AI, Google Workspace Gemini, Salesforce Einstein, Zoom AI Companion, as consumed on managed endpoints.
• Mobile AI apps, own-built mobile applications with AI features, vendor mobile AI assistants on managed mobile devices.
• Edge AI devices, kiosks running on-device inference, IoT devices with AI capability, on-device AI hardware managed by the organization.

Out of scope of the Endpoints domain:

• AI software the organization builds, that is the Software domain (the model and backend serving the endpoint).
• The data classes processed through endpoint AI, that is the Data domain (in particular prompt/completion log corpora).
• The infrastructure that hosts the AI provider backend, that is the Infrastructure domain.
• AI tools and services consumed from third-party vendors as vendor relationships, that is the Vendors domain (cross-referenced for vendor-provided endpoint AI).
• Business workflows that route through endpoint AI, that is the Processes domain.

The subject of every cell in this handbook is the AI-enabled endpoint or user-facing AI interface the organization deploys, manages, or governs. The endpoint is what is being secured.

3. Why a domain-specific handbook

Operating AI on endpoints is not the same as operating classic endpoint software. Five reasons motivate the standalone handbook:

• AI on endpoints creates failure modes classic endpoint security does not address. Regulated data pasted into LLM prompt fields, AI browser extensions reading form content and exfiltrating to AI provider backends, SaaS-AI features silently enabled tenant-wide and ingesting customer documents, mobile AI apps performing on-device inference with unsigned models, edge AI devices physically tampered with and continuing to operate, customer-facing chatbots shipping without EU AI Act Art. 50 disclosure, none of these are surfaced by a generic MDM or DLP baseline.
• Endpoint AI arrives faster than IT and security can follow. An employee installs an AI browser extension; a product manager enables M365 Copilot for a team and it gains SharePoint access; a customer-facing chatbot goes live on the marketing site without security review; a sales team starts using a mobile AI assistant; a retail kiosk begins running on-device facial recognition. None of this is coordinated, each arrives through a different channel (extension marketplace, SaaS admin console, app store, IoT provisioning) and none is visible to the team responsible for endpoint security or AI governance unless the program looks for it deliberately.
• Regulators have addressed endpoint AI specifically. EU AI Act Art. 50 requires disclosure for AI interactions on user-facing surfaces. Art. 26 deployer duties apply to the org that operates a customer-facing chatbot, mobile AI app, or edge AI device. GDPR Art. 32 security of processing applies to regulated data flowing through endpoint AI. Sector rules (HIPAA, PCI-DSS, FERPA, COPPA) apply to endpoint AI processing the regulated data classes.
• Shadow AI on endpoints is the program's primary L1 outcome. Unsanctioned AI browser extensions, SaaS-AI features silently enabled, AI assistant apps installed via personal stores on BYOD, edge AI devices deployed without IT, these ungoverned surfaces are the central problem the L1 program exists to solve.
• Seven archetypes, one program. The seven AI/HAI endpoint archetypes behave differently enough that threats, requirements, reference patterns, and tests are archetype-keyed throughout the handbook.

4. The seven AI/HAI endpoint archetypes

Most of the practices in this handbook key their content to seven archetypes. Knowing the archetypes well is a prerequisite for using the handbook.

1. AI assistant / copilot on managed endpoint. Desktop or IDE-integrated AI assistant calling a vendor or internal LLM API, often with access to local filesystem, clipboard, or developer tooling. Examples: GitHub Copilot, Cursor, Claude Code, internal AI assistants. Risk shape: confidential-data egress to vendor (regulated data, source code, customer data via paste or file context, TM), prompt injection via opened files (AGH), tool-scope creep for tool-using assistants (EA), excessive agency (assistant invokes endpoint tools beyond declared scope).

2. Browser-based AI tool. Extension or web AI interface reading page content, DOM, cookies, or form data; backend is typically a vendor AI provider. Examples: Grammarly AI, page-summarizer extensions, AI screenshot tools. Risk shape: page-content exfiltration via overbroad host permissions (<all_urls>), DOM-write injection (AGH), session-cookie harvesting, exfiltration of form data to AI provider, persistence of installed extensions through updates.

3. Chatbot / conversational UI. Customer-facing or employee-facing conversational interface; own-built or vendor-backed. Risk shape: EU AI Act Art. 50 disclosure failure or suppression, prompt injection via user-turn (AGH; ATLAS AML.T0051), output-filter bypass via jailbreak, customer-data extraction via inference (ATLAS AML.T0024), escalation-path failure, brand-safety failure.

4. Multi-modal AI interface. Accepts image, audio, or video inputs in addition to or instead of text. Examples: voice AI, image-input chatbots, video AI surfaces. Risk shape: image-injection (steganographic prompts), voice-injection, deepfake acceptance (synthetic-face authentication bypass, biometric-spoofing), cross-modal consistency failure (a response safe via text but unsafe via voice), modality-specific safety-filter gaps.

5. AI-augmented productivity (SaaS-AI on endpoint). AI features layered on productivity, CRM, or collaboration suites the organization consumes, M365 Copilot, Slack AI, Notion AI, Workspace Gemini, Salesforce Einstein, Zoom AI Companion. Risk shape: silent enablement at tenant level (shadow AI in SaaS), data-scope creep (Copilot indexes SharePoint sites without scoped governance), no-train flag drift after vendor update, cross-tenant context bleed in shared workspaces.

6. Mobile AI app. Native or hybrid mobile application with on-device or cloud-based AI features and sensor access (camera, microphone, location). Risk shape: on-device model substitution (unsigned model swap via side-load), local-model integrity failure, permission-scope creep (background microphone / camera access), biometric-bypass via synthetic media, mobile-specific data-exfiltration channels.

7. Edge AI device. Physical device running AI inference locally with limited remote management and physical-access exposure. Examples: retail kiosks with on-device image recognition, IoT devices with AI capability, on-device AI hardware. Risk shape: firmware tampering (unsigned firmware flash), model substitution (unsigned model load), physical-tamper attack, uplink-traffic interception, remote-disable failure, model-extraction via device access.

A single endpoint can host more than one archetype simultaneously, a managed laptop running both an AI assistant and an AI browser extension; a SaaS productivity platform with an AI feature plus a browser-launched chatbot. Threat libraries, requirements packs, reference patterns, and tests in this handbook accommodate that.

5. Domain boundary rules

When in doubt about whether something belongs in the Endpoints domain, ask: what is being secured, the endpoint or user-facing AI surface, or something further downstream?

• If the concern is the endpoint AI surface (the assistant, the extension, the chatbot UI, the mobile app, the edge device): it is an Endpoints artifact.
• If the concern is the model backend that powers the surface: Software (own-built) or Vendors (third-party). If the concern is the data class processed: Data. If the concern is the workflow wrapping the AI step: Processes.

Common boundary cases:

• A customer-facing chatbot built in-house is an Endpoints artifact (chatbot / conversational UI archetype); the LLM serving it is a Software artifact; the prompt/completion log corpus is a Data artifact; the workflow wrapping the chatbot in a support process is a Processes artifact.
• A vendor coding assistant (GitHub Copilot) on a managed engineering laptop is an Endpoints artifact (AI assistant on managed endpoint); the vendor relationship is governed by Vendors; the source code paste behavior is an Endpoints-domain DLP concern.
• M365 Copilot enabled tenant-wide is an Endpoints artifact (AI-augmented productivity); the data scope it accesses involves the Data domain; the workflows in which employees use it cross-reference the Processes domain.

6. Stakeholders and roles

The AI/HAI Endpoint Assurance program is cross-functional by design. The following roles appear throughout this handbook:

• Executive sponsor. Typically the CISO co-sponsored by the CIO or Head of IT; co-sponsorship by the CPTO is common where customer-facing chatbots and mobile AI apps are in scope. Owns budget, scope, and decision rights for the program.
• Program lead. Operationally accountable for the program day-to-day. Often the Endpoint Security lead or the AI Security lead. Maintains the AI/HAI endpoint inventory, runs the working group, owns the metrics.
• Cross-functional working group. Security, IT (Endpoint Management, MDM, EDR, browser admin, SaaS admin, identity), Workplace Technology, Engineering and Product (own-built chatbots and mobile AI), Privacy/Legal, and HR (acceptable use). Meets at least monthly.
• Intake reviewers. A small population trained to assess AI/HAI endpoint deployments against the threat library, the requirements pack, and the priority compliance map. Drawn from Endpoint Security, Product Security (for own-built surfaces), and IT.
• Architect reviewers. Senior endpoint and product architects with sign-off authority on design reviews for AI/HAI endpoint deployments.
• Endpoint Management. Owns the MDM/EDR/browser-admin substrate on which Endpoints-domain controls land.
• SaaS Admin. Governs AI-feature enablement in productivity SaaS (M365, Slack, Workspace, Notion).
• Product / Engineering deployer-duty owner. For own-built customer-facing AI surfaces (chatbots, mobile AI apps, edge AI devices), the Art. 26 deployer-duty owner is the product owner who ships the surface.

7. How to use this handbook

Three modes of use are supported:

• Read it linearly. Parts I and II ground the reader in the domain and foundations. Part III walks the twelve practices in the Endpoints-domain context. Part IV provides the assessment instrument. Part V is reference.
• Run an assessment. Skim Parts I and II for context (one to two hours), then go directly to Part IV. The 108 questions are organized by practice and by maturity level, with explicit evidence prompts. Scoring methodology and rollup tables follow.
• Build a program from scratch. Read Part II carefully, then implement the twelve practices' Level 1 in the order described in Part II's dependency text. Use the Level 1 questions in Part IV as a self-check for completeness.

The questions in Part IV are duplicated as a per-practice "Practice Maturity Questions" section at the end of each practice in Part III. They are the same questions; the duplication is deliberate so the practice-by-practice reader sees the assessment instrument inline.

Part II, Foundations

8. The four Business Functions in this domain

The twelve practices group into four Business Functions. Each function exists for a distinct intent. Every practice belongs to exactly one function.

Governance, Strategy & Metrics (SM), Policy & Compliance (PC), Education & Guidance (EG). Establish why, what, who, and how: the program's strategic frame, its enforceable rules, and the workforce literacy that makes everything downstream possible. In this domain, Governance answers: who owns AI/HAI endpoint risk, what policies apply (AUP, browser-extension governance, customer-facing AI disclosure), what training every managed-endpoint user and endpoint AI reviewer must complete, and how a new AI/HAI endpoint deployment enters a sanctioned state.

Building, Threat Assessment (TA), Security Requirements (SR), Secure Architecture (SA). Decide what could go wrong, what the endpoint must do about it, and how the endpoint is shaped to do it, before deployment begins. In this domain, Building answers: what threats AI/HAI endpoint archetypes carry, what requirements every endpoint deployment must meet, what reference patterns IT and product teams should reach for.

Verification, Design Review (DR), Implementation Review (IR), Security Testing (ST). Prove that the designed endpoint, the implemented endpoint, and the running endpoint actually meet the Building-function outputs. In this domain, Verification answers: did the design follow the SA reference pattern, do the live MDM/browser/SaaS-admin state match the design, and does the endpoint actually behave correctly under adversarial probes.

Operations, Environment Hardening (EH), Issue Management (IM), Monitoring & Logging (ML). Run the program safely in production, harden the endpoint envelope, manage the issues, and watch what is actually happening. In this domain, Operations answers: which controls keep sanctioned endpoint AI frictionless and unsanctioned use observable, where AI/HAI endpoint issues go, and what telemetry produces deployer-duty and Art. 50 disclosure evidence on demand.

Cross-function rule: progress in one function without the others is unstable. The handbook is balanced across the four by design. L1 build order follows the dependency graph: SM precedes everything; PC and EG follow SM; TA, SR, and SA follow Governance; DR and ST run after SA L1 exists; IR follows DR; EH, IM, and ML form the Operations layer that depends on SM inventory, SA patterns, and PC policies all being in place.

9. The three maturity levels

Every cell in this handbook is one of three maturity levels. The levels are cumulative, Level 2 assumes Level 1 is in place; Level 3 assumes Level 2 is in place.

Level 1, Foundational. Stand up the minimum viable capability. Discover what AI/HAI endpoint surfaces the organization operates or governs, publish the core policies, run the first version of the controls, baseline the metrics. Typical outputs: an inventory of endpoint AI across all seven archetypes, short published policies (Endpoint AI AUP, AI Browser-Extension Policy, Customer-Facing AI Endpoint Disclosure Policy), per-archetype threat models, per-archetype requirements packs, per-archetype reference patterns, first detections, first logging baselines, AI-specific endpoint incident playbook. Reality check: if the program cannot answer "what AI/HAI endpoint surfaces do we operate or govern, what rules apply to them, and who owns each" within a week, it is not at Level 1.

Level 2, Comprehensive. Calibrate the program's intensity by risk tier. Move from one-size-fits-all to differentiated depth. Replace point-in-time activities with continuous validation. Typical outputs: a published risk-tier rubric, a tier-treatment matrix, per-tier calibrated activities, per-deployment deep threat models for Critical-tier, MDM-encoded and SaaS-admin-encoded reference patterns with conformance checks, scenario-based design reviews, continuous configuration-drift detection, per-tier red-team cadence, tier-calibrated hardening, tier-calibrated logging. Reality check: if the same review effort goes to a Low-tier developer coding assistant and to a Critical-tier customer-facing chatbot, the program is not at Level 2.

Level 3, Industry-Leading. Automate the substrate. Benchmark externally against peers. Contribute back to the AI-assurance ecosystem. Typical outputs: signal-driven inventory and tier updates from MDM/SaaS-admin/identity, machine-readable requirements with endpoint attestation, daily attestation per Critical endpoint, automated adversarial testing, IaC-driven hardening with adaptive tightening from ML and IM signals, detection-as-code, external benchmarking briefs, contributions to MITRE ATLAS, CSA AI Safety Initiative, OWASP MASVS, OWASP Browser-Extension Top 10, OASIS, sector ISACs. Reality check: if all activity is still internally generated, no external contributions, no benchmarking deltas, no automation replacing routine review work, the program is mature for its own purposes but is not industry-leading.

10. HAI-specific threat tactics (EA, AGH, TM, RA)

Four AI-specific threat-tactic categories appear throughout this handbook. In the Endpoints domain they manifest at the user-facing AI surface and on the endpoint device.

EA, Excessive Agency. Endpoint AI granted broader scope than the use case requires, a tool-using AI assistant with shell or file-system access beyond its declared tool allowlist, a browser extension with <all_urls> host permission, a SaaS-AI feature enabled tenant-wide with access to scopes that should be excluded, a mobile AI app with background microphone or camera permission.

AGH, Agent Goal Hijack. Prompt injection at user-facing AI surfaces redirects the AI's purpose, direct injection via chatbot user turn (ATLAS AML.T0051), indirect injection via opened files for AI assistants, page-content injection via browser-extension reads, image- or voice-injection in multi-modal interfaces.

TM, Tool Misuse. Endpoint AI tools and APIs invoked for attacker purposes, assistant invokes endpoint tools to exfiltrate clipboard or screenshot data, browser extension calls its backend AI API to ship sensitive form content, SaaS-AI productivity feature used to bulk-export workspace content.

RA, Rogue Agents. Autonomous AI on endpoints drifts from intended behavior, long-running copilot session accumulates context that shifts its outputs; mobile AI app's on-device model is silently swapped to a compromised version; edge AI device's firmware drifts after physical access.

The four categories sit alongside endpoint-native failure modes, model extraction (AML.T0024), inference exfiltration, browser-extension exfiltration, SaaS-AI silent enablement, mobile-app integrity failure, edge tamper, and are tagged where the threat libraries, requirements, and tests reference them.

11. The priority compliance map

Every Endpoints-domain Policy & Compliance practice at Level 1 publishes (and downstream practices reference) a one-page priority compliance map. The set below is the priority set for the Endpoints domain. Sector-specific items are added as applicable.

The map's purpose is traceability: an auditor or regulator asking "how is Art. 50 disclosure addressed for our customer-facing AI?" should reach a single cell in the map and from there one policy and from there one evidence artifact.

12. Shadow AI in the Endpoints domain (ungoverned AI on endpoints)

Shadow AI in the Endpoints domain takes a specific shape: ungoverned AI on endpoints and user-facing surfaces.

• Shadow endpoint AI is the unsanctioned surface. Self-installed AI browser extensions on managed endpoints, SaaS-AI features silently enabled tenant-wide without security review, AI assistant apps installed via personal stores on BYOD accessing org email, mobile AI apps that gained sensor permissions silently, edge AI kiosks deployed by facilities teams without IT, customer-facing chatbots launched by product teams without intake.
• Shadow endpoint AI compounds quickly. Every week of ungoverned operation increases the data-class exposure and the regulatory blast radius. A shadow AI browser extension reading regulated-PII form content creates a continuing GDPR Art. 32 exposure. A SaaS-AI feature silently enabled tenant-wide with access to confidential M&A documents accumulates daily data exposure to a vendor whose no-train flag has never been verified.
• Shadow endpoint AI is observable today. The signals already exist, MDM/UEM app inventory and install/update events, EDR egress to AI provider domains, browser-extension admin reports, SaaS-admin AI-feature dashboards, identity-OAuth events for AI service authorizations, mobile MDM app inventory, edge device registries. No new tooling is required at L1.
• Shadow endpoint AI manifests through more than one domain. The handbook treats it primarily in SM and EG, but it appears in TA (shadow-endpoint-AI threat view), PC (intake gate amnesty path), EH (MDM allowlist enforcement, browser extension policy, SaaS-AI feature governance), IM (shadow-endpoint-AI containment plays), and ML (shadow-endpoint-AI detection).

Every Level 1 activity in this handbook contributes to making shadow endpoint AI visible, attributable, and trending down. The Level 1 outcome metric "shadow-endpoint-AI ratio" appears in Strategy & Metrics, Policy & Compliance, Education & Guidance, Threat Assessment, Environment Hardening, and Monitoring & Logging, six of the twelve practices. That is intentional.

13. Metrics taxonomy

Every level block in this handbook carries three metric types. The taxonomy is the canonical vocabulary; examples and targets are practice-specific.

• Outcome metrics (lagging). Directly measure whether the level's goal was achieved. Reported monthly or quarterly. Stated in a four-column table: Metric · Baseline · Target · Source.
• Process metrics (leading). Predict outcome metrics by measuring execution. Reported weekly or at the cadence of the underlying activity.
• Effectiveness metrics (business value). Measure what the outcome means to the business. Reported quarterly, often qualitative supported by quantitative.

Metric selection follows two rules: SMART (specific, measurable, achievable, relevant, time-bound) and outcome over output (results are preferred to activity counts). If a metric does not have a baseline column, the baseline is the value the program records on first measurement. The first cycle of measurement is itself an L1 activity.

Part III, The Twelve Practices in the Endpoints Domain

Each practice section follows the same shape:

• Practice Overview. Objective, description, context.
• Maturity Level 1. Objective, activities (A, B, C), outcome metrics, success criteria.
• Maturity Level 2. Same structure.
• Maturity Level 3. Same structure.
• Common Pitfalls. Three to four per level.
• Practice Maturity Questions. Three yes/no questions per level, the same questions also appear in the Part IV assessment workbook.

14. Strategy & Metrics (SM)

Practice Overview

Objective: Stand up an AI/HAI Endpoint Assurance program that discovers, inventories, and strategically governs the AI/HAI-enabled endpoints and user-facing AI interfaces the organization deploys, manages, or governs, with shadow endpoint AI prevention as the primary L1 outcome and a defensible risk-tier rubric as the primary L2 deliverable.

Description: SM-Endpoints establishes the program charter, the authoritative inventory of AI/HAI endpoint assets the organization operates, and the practice-maturity metrics that prove the program is working. The Endpoints domain governs the AI/HAI capabilities living at the endpoint layer across seven archetypes: AI assistants and copilots on managed endpoints (Cursor, Copilot, Claude Code, internal AI assistants on engineering laptops), browser-based AI tools (web UIs, AI browser extensions such as Grammarly AI, page summarizers, screenshot tools), chatbots and conversational UIs (own-built customer-facing chat surfaces), multi-modal AI interfaces (voice, image, video AI on endpoints), AI-augmented productivity (M365 Copilot, Slack AI, Notion AI, Google Workspace Gemini on managed endpoints), mobile AI apps (own-built mobile AI apps and vendor mobile AI assistants on managed mobile devices), and edge AI devices (kiosks, IoT, on-device inference). SM-Endpoints L2 produces the risk-tier rubric every other Endpoints-domain L2 practice depends on per the v3.0 dependency graph.

Context: AI capabilities arrive at endpoints from every direction simultaneously and through every channel except the one that owns endpoint security. An engineer installs a coding copilot from the extension marketplace; a product manager enables M365 Copilot for a team and it quietly gains SharePoint access; a customer-facing chatbot goes live on the marketing site without a security review; a sales team starts using a mobile AI assistant that ships call transcripts to an offshore vendor server; a retail kiosk begins running on-device image recognition that collects biometric-adjacent data. None of this is coordinated, each arrives through a different channel (MDM app catalog, browser-extension policy, SaaS admin console, app store, IoT provisioning), each creates a different data-exposure and AI-decision surface, and none of it is visible to the team responsible for endpoint security or AI governance unless the program looks for it deliberately. The AI/HAI Endpoint Assurance program makes this surface visible, attaches accountable ownership, and operationalizes the distinction between own-built endpoint AI (in scope here as primary subject) and vendor AI consumed on endpoints (cross-referenced with the Vendors domain).

Maturity Level 1

Objective: Stand up the AI/HAI Endpoint Assurance program, build an inventory of AI/HAI endpoint assets across all seven archetypes, and establish baseline metrics that prove shadow endpoint AI is decreasing.

Activities.

A) Charter the AI/HAI Endpoint Assurance program. Publish a short program charter that names the problem (shadow AI at the endpoint layer, AI features silently enabled in SaaS productivity suites, own-built customer-facing AI surfaces shipped without security review, AI browser extensions exfiltrating sensitive content, edge devices running unreviewed on-device models), defines scope across all seven endpoint AI archetypes, and assigns accountable ownership. Charter elements include a problem statement grounded in endpoint-layer AI failure modes (data-egress through model APIs, undisclosed customer-facing AI interfaces, autonomous endpoint AI acting on data users paste without understanding the downstream flow, EU AI Act Art. 50 transparency obligations on own-built customer-facing AI, GDPR Art. 32 endpoint-security obligations on personal-data processing through AI); the seven in-scope archetypes (AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device); domain-boundary rules (own-built endpoint AI governed primarily here; vendor AI consumed on endpoints cross-referenced with Vendors); an executive sponsor (CISO co-sponsored by CIO / Head of IT / CPTO; co-signed by Privacy/Legal where customer-facing archetypes are in scope); a working group spanning Security, IT (Endpoint Management, MDM, EDR), Engineering (own-built chatbot and mobile AI), Product, Workplace Tech, AI/ML engineering, Privacy/Legal, and HR (acceptable use); decision rights for approval, block, exception, and go-live; and a numerical year-one success target tied to the L1 outcome metrics.

B) Build the AI/HAI endpoint inventory and discover shadow endpoint AI. Establish a single AI/HAI endpoint inventory as the program's source of truth. Minimum inventory fields are asset name, owning team or responsible owner, archetype (one of the seven), endpoint population affected (number of endpoints; user-role mix: customer-facing, employee-general, developer-only, executive, regulated-role), own-built versus vendor-provided (and if vendor-provided, cross-reference to Vendors inventory), data classes accessible through the endpoint AI (regulated PHI / PCI / regulated PII / source code / customer confidential vs. internal vs. public), action capability (read-only vs. action-taking on org or customer systems), customer-data egress potential (does the endpoint AI ship user-provided or observed data to a vendor AI backend?, yes/no with cross-reference to DPA status), deployment scale (number of endpoints; concentration in critical roles), regulatory scope (EU AI Act Art. 50 transparency trigger for own-built customer-facing AI; sector triggers, HIPAA, PCI-DSS, FERPA, COPPA), approval status (Sanctioned / Provisional / Under review / Prohibited / Awaiting Intake), risk tier (populated at L2), and linked artifacts (TA threat snapshot, PC compliance-map entry, latest DR decision for own-built surfaces, latest IR finding, ML logging-baseline status). Discovery at L1 uses signals IT, security, and SaaS-admin teams already have: MDM/UEM telemetry (Jamf, Intune, Kandji, VMware Workspace ONE) for app inventory and install/update events on managed endpoints filtered to AI categories; EDR telemetry (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) for process execution and network egress to AI provider domains (openai.com, anthropic.com, api.github.com/copilot, Azure / Google AI endpoints, grammarly.com, notion.so, Slack/M365/Workspace AI features); browser-extension inventory from Chrome Enterprise Admin, Edge Admin Center, and Firefox Enterprise Policy filtered to AI capabilities; SaaS admin consoles for AI feature enablement (M365 Copilot license assignment, Slack AI per-workspace, Notion AI, Gemini for Workspace); identity-OAuth signals from Okta / Entra ID / Workspace SSO for AI service authorizations; customer-facing AI self-attestation from product owners; mobile app inventory from MDM mobile (iOS / Android) and own-built mobile app release notes; IoT and kiosk asset registries for edge devices running on-device inference; and a 60-second self-attestation form publicized to engineering, product, and IT with an amnesty window for previously undisclosed AI tools and surfaces.

C) Establish foundational metrics that measure practice maturity and shadow endpoint AI reduction. Baseline and track a small, automatable set of outcome, process, and effectiveness metrics tied to the L1 outcome (shadow endpoint AI reduction across all seven archetypes and inventory coverage of what the org operates at endpoints). Publish a quarterly shadow endpoint AI scoreboard to the executive sponsor reporting total inventory by approval status broken out by archetype, new endpoint AI assets discovered this quarter and their intake status, shadow-endpoint-AI ratio trend across the last four quarters, Endpoint AI AUP attestation coverage across the managed-endpoint user population, and the top five unmitigated endpoint AI risks (TA-flagged, MDM/EDR-flagged, customer-facing-surface-flagged, or external-advisory-flagged) with owners and remediation status. Keep activity counts (devices scanned, tickets closed) out of the outcome view, they belong to process metrics.

Outcome Metrics (L1).

Success Criteria.

• Program charter published and sponsored by an accountable executive (CISO co-sponsored by CIO / Head of IT / CPTO) with a cross-functional working group spanning Security, IT/Endpoint Management, Engineering, Product, Workplace Tech, AI/ML, Privacy/Legal, and HR.
• AI/HAI endpoint inventory exists as a single source of truth covering all seven archetypes with ≥90% coverage of discovered endpoint AI assets within 12 months, broken out by archetype.
• Shadow-endpoint-AI ratio baselined and trending down for two consecutive quarters.
• ≥95% of managed-endpoint users have acknowledged the Endpoint AI AUP.
• Quarterly shadow endpoint AI scoreboard delivered to the executive sponsor with archetype-level breakdown.

Maturity Level 2

Objective: Risk-tier the AI/HAI endpoint inventory using a seven-dimension rubric, calibrate program intensity per tier, and measure practice maturity and shadow-endpoint-AI reduction per tier, establishing the tier rubric every other Endpoints-domain L2 practice depends on.

Activities.

A) Define the AI/HAI endpoint risk-tier rubric. Four tiers, Critical / High / Medium / Low, assigned from seven auditable dimensions specific to AI/HAI endpoint assets: user exposure (customer-facing public with no authentication required → Critical; authenticated customer of own products → High; employee-general → Medium; developer-only or IT-only → Low); data sensitivity processed on the endpoint (regulated PHI / PCI / regulated PII / customer source code / customer confidential accessible to or processable by the AI at the endpoint → elevate to Critical or High; internal-only data → Medium; public data only → Low); decision-affecting use (GDPR Art. 22 automated decisioning, EU AI Act Annex III high-risk use cases, hiring, credit, education, biometrics, critical infrastructure, law enforcement, essential services, reached or influenced by the endpoint AI → Critical); agentic capability on the endpoint (AI takes actions on org or customer systems, writes records, sends messages, executes commands, submits forms, modifies files, initiates workflows → elevate; read-only informational AI → no elevation); endpoint criticality (managed endpoints in critical roles, finance, legal, clinical, executive, customer support, or shared kiosk/edge devices with physical access exposure → elevate; BYOD or unmanaged-by-default endpoints with regulated-data access → elevate; standard managed endpoints in non-critical roles → neutral); regulatory scope (EU AI Act Art. 50 transparency obligation triggered for own-built customer-facing AI → elevate; sector trigger, HIPAA endpoint, PCI-DSS cardholder-data-environment endpoint, FERPA educational endpoint, COPPA children-facing AI → Critical); distribution scale (large managed-endpoint population, broad customer reach, or concentration in regulated workflows → elevate; small population or contained scope → neutral). The rubric is documented as a short table; tier is derived deterministically from the dimensional inputs; human overrides are allowed but recorded with rationale and reviewed by the working group.

B) Calibrate program intensity per tier. Publish a tier-treatment matrix defining what each tier receives from each downstream Endpoints-domain practice, intake depth, TA depth, SA pattern adherence, DR lane, IR cadence and re-review triggers (model swap, new tool, new data class, new action capability, scope change), ST battery and adversarial cadence, EH controls (MDM policy enforcement, browser-extension DLP, SaaS-admin AI feature gating, egress allowlist), ML detection set, and IM SLAs by severity. Critical artifacts receive the full program, per-asset deep threat model with customer-data-egress and action-scope overlay; full SR pack with REM and explicit Art. 50 disclosure UX review; full-lane DR with a named architect; semi-annual IR plus mandatory re-review within 14 days of any material change; full ST battery (data-egress canaries, prompt-injection corpus, action-scope boundary, jailbreak regression, disclosure-UX verification, kill-switch) plus quarterly adversarial exercises; all EH controls; tuned detections with full endpoint-AI egress, interaction, and identity logs; Critical IM SLAs (ack ≤4h, mitigate ≤48h, root-cause ≤30d); and executive plus privacy-officer sign-off. Low artifacts use the fast-track, archetype-level threat snapshot, base SR pack, no required DR, spot-check ST, baseline MDM policy, baseline logging, and Low-tier IM SLAs (ack ≤5BD, mitigate ≤30d). High and Medium fall between. Each downstream Endpoints-domain L2 practice (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) inherits this calibration; the rubric and matrix are authored here in SM-Endpoints L2 and changes flow through the SM working group.

C) Per-tier scoreboard and governance. The L1 shadow endpoint AI scoreboard becomes tier-aware. Inventory state is reported by tier and by archetype, a Critical-tier customer-facing chatbot processing regulated PII with action-taking capability is its own row; the count of Low-tier developer-only coding assistants is one line. Shadow-endpoint-AI ratio is reported per tier, a Critical-tier unsanctioned own-built chatbot is a headline, a Low-tier unsanctioned coding assistant is a line item. Per-tier SLA adherence across intake, DR, IR, ST, ML, and IM is reported monthly. The tier-movement log records upgrades (an endpoint AI asset that gained customer exposure, action-taking capability, or regulated-data access) and downgrades with rationale, reviewed by the program sponsor. Quarterly executive review explicitly discusses tier-balance, is the program's effort matching the risk profile of the endpoint AI surface?

Outcome Metrics (L2).

Success Criteria.

• Risk-tier rubric published and applied; tier assigned to 100% of inventory from auditable dimensions (user exposure, data sensitivity, decision-affecting use, agentic capability, endpoint criticality, regulatory scope, distribution scale).
• Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it.
• Per-tier shadow endpoint AI ratio reported quarterly; Critical-tier unsanctioned endpoint AI in production = 0.
• Per-tier SLA adherence ≥90% across practices.
• Tier-movement governance active, changes logged with rationale and reviewed by the sponsor.

Maturity Level 3

Objective: Automate inventory and tier maintenance from MDM, browser, SaaS-admin, identity-OAuth, deployment, and edge-device signals; benchmark the program against external endpoint-AI peers; and contribute anonymized endpoint-AI assurance intelligence back to the industry.

Activities.

A) Continuous inventory and tier automation from MDM, browser, SaaS-admin, identity, deployment, and edge signals. Inventory auto-updates from MDM app catalog events (new AI app installed or updated on a managed endpoint), browser-extension admin policy changes (new AI extension approved, added, or removed from the allowlist; permission-scope changes), SaaS-admin AI-feature enablement events (M365 Copilot license assignment, Slack AI per-team activation, Notion AI workspace flip, Gemini for Workspace rollout), identity-OAuth events (new AI service OAuth authorization from a managed endpoint), own-built AI surface deployment events (chatbot version release, mobile AI app release with new AI features), edge-device firmware events (on-device model update, new inference capability added), runtime egress (new outbound flow to an AI provider domain), self-attestation, and the intake queue. Tier assignments are rule-based on the L2 rubric inputs; rule changes are versioned and replayable; tier changes auto-trigger downstream practice obligations within 24 hours (a Medium-to-Critical upgrade triggers DR, ST, ML reconfiguration, and Art. 50 disclosure UX review). Human curation handles new archetypes, ambiguous discoveries (a shared productivity tool that sometimes has AI features enabled), and dimensional-input conflicts (a tool classified employee-only that is also used in a customer-facing workflow). A data-quality SLO is published: ≥99% of active AI/HAI endpoint assets correctly tiered within 48 hours of a material change; ≥95% inventory completeness against discovery-source reconciliation.

B) External benchmarking. Program metrics are compared against peer benchmarks through the CSA Endpoint Security Working Group and CSA AI Safety Initiative, OASIS AI governance working groups relevant to endpoint and conversational AI, mobile-AI ISACs and sector-specific groups (FS-ISAC, H-ISAC, IT-ISAC mobile and endpoint tracks), OWASP MASVS (Mobile Application Security Verification Standard) for own-built mobile AI app benchmarking, BSIMM-style observational data on what peer organizations govern at the endpoint AI layer, formal peer roundtables (CISO communities and endpoint security practitioners with AI workloads), and CIS Critical Security Controls and OpenSSF AI working groups where endpoint scope applies. A semi-annual "how we compare" brief covers inventory coverage, shadow-endpoint-AI ratio, per-tier SLA adherence, automation level, Art. 50 disclosure UX compliance rate, endpoint-AI data-egress control coverage, and time-from-intake-to-provisional-approval. Benchmark deltas inform program investment, board-level narrative, and the next year's L2 and L3 work priorities.

C) Contribute anonymized endpoint-AI assurance intelligence. Contribute to the CSA AI Safety Initiative (endpoint-AI controls matrix, browser-extension governance guidance, SaaS AI feature governance reference), OWASP MASVS and the OWASP Mobile Application Security Testing Guide for own-built mobile AI security patterns, OASIS conversational AI and chatbot security standards, NIST AI RMF Playbook deployer-duty evidence patterns for endpoint-facing AI, EU AI Act Art. 50 transparency implementation guidance (reference UX patterns for own-built conversational and multi-modal AI interfaces), CIS Critical Security Controls extensions for AI-capable endpoints, OpenSSF AI working groups, and sector ISACs where endpoint-AI working groups accept practitioner input. Target minimum four substantive contributions per year; quality over volume; every contribution anonymized and legally vetted.

Outcome Metrics (L3).

Success Criteria.

• Inventory auto-update SLO published and met; tier-rule change-log versioned and replayable.
• Tier-assignment automation operational with exception-based human review; tier changes auto-trigger downstream obligations within 24 hours.
• Semi-annual external-benchmarking brief published to the sponsor with ≥5 peer-comparable metrics from CSA, OASIS, OWASP MASVS, sector ISACs, CIS, and OpenSSF AI.
• ≥4 substantive industry contributions per year, anonymized and cited.
• Executive / board ROI narrative refreshed at least annually with external benchmarks and avoided-loss examples.

Common Pitfalls

Level 1. - Inventory is seeded only from "AI tools IT knows about", misses browser extensions installed by users without IT approval, AI features silently enabled by SaaS admins in productivity tools, own-built chatbots launched by product teams without security notification, and mobile AI apps installed on managed devices via personal App Store accounts. - Treating all endpoint AI as a Vendors-domain concern, own-built chatbots, mobile AI apps, and edge AI devices are first-party endpoint surfaces with deployer-duty obligations; the vendor question is a sub-concern for vendor-provided AI consumed at endpoints. - Discovery is passive (waiting for IT tickets) rather than active, MDM app telemetry, browser-extension admin reports, and SaaS-admin AI-feature dashboards exist but no one pulls them monthly. - Executive sponsor is IT-only; CISO and product/engineering leadership are not co-owners, so the program cannot govern own-built customer-facing AI surfaces or coordinate with AppSec. - Metrics count devices scanned rather than outcomes, shadow endpoint AI ratio is never baselined; the program cannot demonstrate shadow AI is decreasing. - Inventory archetypes are too coarse ("AI app on endpoint"), a Critical customer-facing chatbot and a Low developer coding assistant get conflated; the program cannot tier later without re-inventorying.

Level 2. - Tier-rubric inputs are subjective ("important endpoint," "sensitive data"), reviewers tier differently, auditors do not trust it, tier movements feel political rather than mechanical. - Tier-treatment matrix published but not enforced, Critical own-built chatbots routed through the same fast-lane as Low coding assistants; calibration exists on paper only. - Scoreboard still reported in aggregate, hiding that Critical-tier shadow endpoint AI is present because overall averages look acceptable. - Tier upgrades get resistance from product and IT teams because they trigger more review, without governance on tier-movement, the program stays stuck at initial under-tiered assignments. - Downstream practices treat tier as advisory, DR, IR, ST, ML do not differentiate scope by tier, defeating the purpose of L2. - Rubric over-engineered, too many dimensions, tier derivation becomes an oracle ritual; IT and product teams cannot apply it without security acting as intermediary.

Level 3. - Automation runs without a data-quality SLO, signal-driven inventory silently drifts and IT teams stop trusting it. - Benchmarking chooses peers that flatter the program (Series-A startups without customer-facing AI when operating at enterprise scale with regulated data; internal-tool builders when shipping customer-facing chatbots). - Industry "contributions" are conference talks about the program rather than technical artifacts that land in CSA / OWASP MASVS / OASIS / NIST / CIS / OpenSSF AI working group deliverables. - Tier-change automation fires too noisily, every SaaS minor update triggers re-review; IT teams disable the signal-source rather than tune rule sensitivity. - ROI narrative decouples from reality, external benchmarks cited but the program's own metrics are stale; the sponsor stops trusting the briefing deck.

Practice Maturity Questions

Level 1. 1. Is there a published AI/HAI Endpoint Assurance program charter with a named executive sponsor (CISO co-sponsored by CIO / Head of IT / CPTO), a cross-functional working group spanning Security, IT/Endpoint Management, Engineering, Product, Workplace Tech, AI/ML, Privacy/Legal, and HR, and clear decision rights for approval, block, exception, and go-live across all seven endpoint AI archetypes? Evidence: charter document with sponsor signatures and working-group roster. 2. Does a single AI/HAI endpoint inventory exist, seeded from MDM, EDR, browser-extension admin, SaaS-admin console, identity-OAuth, customer-facing AI self-attestation, mobile app store / MDM mobile, and IoT asset-registry signals, covering all seven archetypes with ≥90% coverage of discovered endpoint AI assets within 12 months? Evidence: inventory export reconciled against discovery-source query results. 3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow endpoint AI ratio (≤15% trending down), Endpoint AI AUP attestation (≥95% of managed-endpoint users), named-owner coverage (100%), and known data-exposure events from endpoint AI assets? Evidence: most recent quarterly shadow endpoint AI scoreboard deck.

Level 2. 1. Is every AI/HAI endpoint asset in the inventory assigned a risk tier based on an auditable rubric covering user exposure, data sensitivity processed on the endpoint, decision-affecting use (EU AI Act Annex III / GDPR Art. 22), agentic capability on the endpoint, endpoint criticality (BYOD vs. managed; critical-role concentration), regulatory scope, and distribution scale? Evidence: rubric document plus inventory column showing tier and derivation inputs per asset. 2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier endpoint AI assets receiving full-scope treatment in the last 12 months? Evidence: tier-treatment matrix plus cross-practice adherence report for Critical assets. 3. Does the quarterly shadow endpoint AI scoreboard report per tier and per archetype (with Critical-tier unsanctioned endpoint AI in production tracked at zero), and is tier-movement logged and reviewed by the sponsor? Evidence: tier-aware scoreboard and tier-movement log for the prior two quarters.

Level 3. 1. Do inventory and tier assignment auto-update from live MDM, browser-extension admin, SaaS-admin, identity-OAuth, own-built AI surface deployment, edge-device firmware, runtime-egress, and self-attestation signals with a published data-quality SLO, and is ≥80% of curation handled automatically with exception-based human review? Evidence: pipeline diagram, SLO dashboard, and curation-source breakdown. 2. Do you publish a semi-annual external-benchmarking brief comparing the program against ≥5 peer-comparable metrics via CSA / OASIS / OWASP MASVS / sector ISACs / CIS / OpenSSF AI, and does it drive investment decisions? Evidence: most recent brief and a budget or staffing decision traceable to a benchmark delta. 3. Does the program contribute ≥4 substantive, anonymized artifacts per year to the endpoint-AI assurance ecosystem (CSA AI Safety Initiative, OWASP MASVS, OASIS, NIST AI RMF, EU AI Act Art. 50 implementation guidance, CIS, OpenSSF AI, sector ISACs), and does the ROI narrative cite external benchmarks? Evidence: contribution log with acceptance confirmations and the most recent ROI narrative.

15. Policy & Compliance (PC)

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Endpoint Assurance program enforceable, so every AI/HAI-enabled endpoint and user-facing AI interface the organization operates is governed by documented rules, gated before it goes live, and defensible to auditors and regulators.

Description: PC-Endpoints codifies three priority policies specific to the Endpoints domain, an Endpoint AI Acceptable Use Policy governing what AI tools may be installed on managed endpoints and what data may flow through them, an AI Browser-Extension Policy establishing an extension allowlist with DLP integration and per-extension data-class restrictions, and a Customer-Facing AI Endpoint Disclosure Policy capturing EU AI Act Art. 50 disclosure UX requirements for own-built chatbots, voice interfaces, and multi-modal AI surfaces. It maps those policies to the compliance regimes that directly apply to the endpoint AI assets the organization operates: EU AI Act Art. 50 (transparency obligation for user-visible AI), Art. 26 (deployer duties), Art. 9 (risk management), Annex III high-risk triggers; GDPR Art. 22 (automated decision-making via endpoint), Art. 32 (security of processing including endpoint), Art. 25 (privacy by design); ISO/IEC 42001 AIMS; ISO/IEC 27001 endpoint controls (A.8.1, A.8.7, A.8.19); SOC 2 CC6; and sector-specific rules where applicable (HIPAA, PCI-DSS, FERPA, COPPA).

Context: Organizations that manage endpoints inherit a generic Acceptable Use Policy and an IT security policy that mentions "authorized software." Neither answers the questions AI/HAI endpoints raise: which AI browser extensions are permitted and under what data-class restrictions; who may enable M365 Copilot for a team that processes regulated data; what disclosure must appear in the UI of an own-built customer chatbot to satisfy EU AI Act Art. 50; what consent basis applies when a mobile AI app accesses device microphone or camera for multi-modal interaction; what the Art. 26 deployer-duty obligation requires from the product team that shipped the chatbot. Without AI-specific endpoint policies and an explicit compliance map, endpoint AI accumulates outside governance, customer-facing AI surfaces go live without mandatory disclosures, and auditors cannot trace a regulation to a control. PC-Endpoints governs what the organization operates at endpoints, in contrast to PC-Software (what it builds) and PC-Vendors (what it consumes from third parties).

Maturity Level 1

Objective: Publish the three priority AI/HAI endpoint policies, map them to the priority compliance requirements, and operate the intake gate that prevents ungated endpoint AI from going live.

Activities.

A) Publish the three priority AI/HAI endpoint policies. Ship each in its smallest useful form, short, readable, specific enough to be enforceable against IT, engineering, product, and user decisions. The Endpoint AI Acceptable Use Policy enumerates sanctioned AI tools (those in the SM-Endpoints inventory) and requires intake for any tool not in the inventory, prohibits use of personal accounts on AI tools (to ensure organizational DPA terms apply), restricts data classes by tool category (regulated data, PHI / PCI / regulated PII / customer confidential / source code, may not be input as prompts, paste actions, file uploads, or screen shares into AI tools unless the tool's DPA covers that class and Privacy has approved), gates AI browser extensions to the allowlist established by the AI Browser-Extension Policy, restricts SaaS AI feature enablement (M365 Copilot, Slack AI, Notion AI, Workspace Gemini) to IT or SaaS admins with documented approval (self-service enablement prohibited), prohibits shipping own-built customer-facing chatbots, mobile AI apps, or edge AI devices without intake and go-live gate review, and requires attestation at onboarding and annually. The AI Browser-Extension Policy operates allowlist-only enforcement via browser enterprise policy (Chrome Enterprise Admin, Edge Admin Center, Firefox Enterprise Policy), defines the review and approval process (vendor identity and DPA, data transmitted to vendor AI backends, permission scope across clipboard, browsing history, page content, stored credentials, and network access, user-population scope on managed endpoints), annotates each approved extension with the data classes permitted through it, integrates with browser-level DLP (Microsoft Purview, Chrome DLP, CASB browser agent) to flag or block regulated-data entry into AI extension interfaces, requires removal of discovered unapproved extensions within 5 business days, and logs exceptions with owner, rationale, and 90-day review. The Customer-Facing AI Endpoint Disclosure Policy applies to all own-built AI surfaces that interact directly with end users (chatbots, conversational UIs, voice AI, multi-modal AI, AI-augmented support tools with AI-generated outputs visible to users), mandates user notification when AI generates outputs a user might mistake for human-produced (prior to or at the start of interaction; clear, prominent, accessible), requires marking of synthetic media (AI-generated images, video, audio) per Art. 50, requires disclosure UX to meet WCAG 2.1 AA accessibility standards (not buried in terms-of-service text), adds sector overlays where applicable (HIPAA patient-facing AI, COPPA children-facing AI, FERPA student-facing AI), integrates with the go-live gate (the disclosure UX specification is a required artifact for all customer-facing AI surfaces), and requires a named deployer-duty owner per customer-facing AI surface.

B) Map the three policies to the priority compliance requirements. Build a one-page priority compliance map an auditor can read in 60 seconds. The map ties EU AI Act Art. 50 transparency obligation to the Customer-Facing AI Endpoint Disclosure Policy (disclosure UX specification and synthetic-content marking); Art. 26 deployer duties to the Endpoint AI AUP (own-built endpoint AI controls, deployer-duty owner requirement) plus the go-live gate (deployer-duty owner assignment, logging baseline confirmation); Art. 9 risk management to the Endpoint AI AUP (intake required for own-built AI surfaces) plus the gate checklist (TA, SR, ST required artifacts for high-risk archetypes); Annex III high-risk deployer obligations to the Endpoint AI AUP (Annex III assessment at intake for applicable archetypes); GDPR Art. 22 to the Endpoint AI AUP (output-integrity-critical / decision-affecting flag triggers safeguards) plus the gate (Art. 22 safeguards checklist); Art. 32 security to the Endpoint AI AUP (data-class restrictions, DLP enforcement) plus the AI Browser-Extension Policy (DLP integration, data-class annotation); Art. 25 privacy by design to the Customer-Facing AI Endpoint Disclosure Policy (consent and disclosure before AI data collection) plus the Endpoint AI AUP (data-class restrictions). ISO/IEC 42001 AIMS traces to the program charter (from SM) plus the three L1 policies; ISO/IEC 27001 endpoint controls (A.8.1, A.8.7, A.8.19) trace to the Endpoint AI AUP (sanctioned-tool requirement, personal-account prohibition) plus the AI Browser-Extension Policy; SOC 2 CC6 traces to the Endpoint AI AUP (MDM/policy enforcement) plus the AI Browser-Extension Policy (allowlist technical enforcement). Sector-specific rules, HIPAA endpoint controls flow into the Endpoint AI AUP (regulated-data restriction for ePHI) plus the Customer-Facing AI Endpoint Disclosure Policy (patient-facing sector overlay); PCI-DSS endpoint controls flow into the Endpoint AI AUP (sanctioned-tool requirement for CDE endpoints) plus the AI Browser-Extension Policy (DLP for cardholder data); FERPA flows into the Endpoint AI AUP (student-records restriction) plus the Customer-Facing AI Endpoint Disclosure Policy (student-facing overlay); COPPA flows into the Customer-Facing AI Endpoint Disclosure Policy (parental-consent UX specification).

C) Operate the intake gate and track foundational compliance outcomes. Run a single intake ticket queue with a published SLA (triage within 5 business days; provisional approval within 10 BD for Low-tier, developer-only coding assistant, no regulated data, read-only, no customer exposure). The artifacts checklist is archetype-keyed, the engineer, product owner, or IT requester submitting intake receives the checklist for their archetype; missing artifacts block go-live for Critical/High. Customer-facing AI surfaces require a disclosure UX specification reviewed against the Customer-Facing AI Endpoint Disclosure Policy as a go-live artifact; no customer-facing AI goes live without a disclosure review record. Gate approval creates or updates the SM-Endpoints inventory record with artifact links and deployer-duty owner. The amnesty path is linked from the intake form, the AUP, the IT helpdesk portal, and the eng-all-hands communications from SM; AI endpoint assets already in production without gate passage may enter through retroactive intake without penalty, with gaps tracked as open IM findings. Exceptions are logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review.

Outcome Metrics (L1).

Success Criteria.

• Three priority policies (Endpoint AI AUP, AI Browser-Extension Policy, Customer-Facing AI Endpoint Disclosure Policy) published, approved by Legal/Privacy and Security, and communicated to all managed-endpoint users and relevant engineering/product/IT teams.
• One-page priority compliance map published covering EU AI Act Art. 50/26/9/Annex III, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, and applicable sector-specific obligations (HIPAA, PCI-DSS, FERPA, COPPA); linked from each policy.
• Intake gate operational with a per-archetype artifacts checklist, a required disclosure UX review for customer-facing surfaces, published SLA, and visible amnesty path.
• ≥95% of managed-endpoint users have acknowledged the Endpoint AI AUP in the current year.
• ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months passed the gate; 100% for Critical/High-tier; every customer-facing or decision-affecting endpoint AI surface has a named deployer-duty owner and a disclosure UX record.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI/HAI endpoint risk tier, automate disclosure UX attestation and artifact assembly from the SM-Endpoints tier rubric, and produce audit-ready evidence trails continuously.

Activities.

A) Tier-calibrated policy depth and sign-off requirements. Extend the three L1 policies with tier-specific addenda using the SM-Endpoints L2 tier rubric. Critical artifacts (customer-facing public AI surfaces with regulated data or action capability) require full SR pack with REM, executive (CISO or CPTO) plus privacy-officer sign-off before go-live, EU AI Act Art. 50 disclosure UX specification reviewed by Legal, GDPR Art. 22 safeguards reviewed by Privacy, consent-management implementation confirmed with WCAG 2.1 AA accessibility audit, sector-specific disclosure package where applicable (HIPAA / COPPA / FERPA), Art. 26 deployer-duty checklist completed and named human-oversight owner assigned, and mandatory re-review within 14 days on every material change (model swap, new capability, scope expansion, new user population). High artifacts (authenticated customer surfaces or employee-facing AI processing regulated data) require full SR pack plus REM with fast-track exemptions, CISO-delegated security lead sign-off, EU AI Act and GDPR assessments, disclosure UX review for customer-facing surfaces, and re-review within 30 days on material change. Medium artifacts (employee-general AI with internal data access or limited action capability) use base SR pack plus REM with fast-lane DR (or DR waiver for sanctioned reference-pattern implementations) and re-review annually or within 60 days on material change. Low artifacts (developer-only coding assistants, read-only, no customer exposure, no regulated data) use base SR pack with self-attested checklist and re-review at annual review. Policy exceptions require named owner, compensating control, Legal/Security reviewer acknowledgment, and expiry date (max 12 months); Critical-tier assets have no amnesty for missing go-live artifacts after L2 is established, missing artifacts (including missing disclosure UX records for customer-facing AI) become blocking findings routed through IM.

B) Continuous compliance evidence assembly and disclosure UX attestation tracking. For every Critical and High AI/HAI endpoint asset, maintain a live compliance evidence bundle that auto-assembles the current TA snapshot (age vs. last material change threshold), the SR REM with gap status and owner, the SA reference-pattern confirmation or DR-approved deviation record, the latest DR decision and date, the latest IR attestation or finding log if IR found drift, ST evidence (test battery last-run date, prompt-injection corpus last-run date, action-scope boundary test last-run date, data-egress canary last-run date), ML logging-baseline confirmation with last-validated date, the deployer-duty record (named human-oversight owner, disclosure mechanism confirmation, Art. 26 and Art. 50 obligations checklist), the disclosure UX attestation for Critical/High customer-facing assets (current disclosure UX specification version, last accessibility review date, last compliance review against the Customer-Facing AI Endpoint Disclosure Policy), and sector compliance artifacts where applicable (HIPAA patient-facing AI consent record, COPPA parental consent mechanism confirmation, FERPA student-data handling record, PCI-DSS cardholder-environment endpoint control evidence). Staleness rules trigger PC-Endpoints findings routed to IM: Critical TA snapshot 90 days, IR attestation 6 months, ST evidence 30 days, disclosure UX attestation 90 days. The evidence bundle is the primary artifact a regulator or auditor receives when asking about a specific endpoint AI asset.

C) Exception management and tier-aware enforcement. Integrate the exception register with the intake gate, no exception approved without tier-appropriate compensating control and expiry. Monthly exception aging review escalates exceptions more than 90 days past expiry to the program sponsor. Sector-specific evidence bundles (HIPAA patient-facing AI bundle, PCI-DSS endpoint bundle, FERPA educational AI bundle, COPPA children-facing AI bundle) are generated from the compliance evidence bundle for the assets they apply to; completeness tracked. Enforcement asymmetry: Critical-tier assets with missing go-live artifacts (including missing disclosure UX records for customer-facing AI) are blocking findings; no amnesty applies post-L2. Browser-extension allowlist review cycle, the allowlist is formally reviewed quarterly; approved extensions with material vendor changes (new data transmitted, new permission scope, vendor acquisition) are flagged for re-review within 30 days of the change.

Outcome Metrics (L2).

Success Criteria.

• Three priority policies extended with tier-specific addenda; 100% of Critical assets carry executive plus privacy-officer sign-off at go-live in the last 12 months.
• Compliance evidence bundle live for every Critical/High asset; staleness inside tier-specific targets.
• 100% of Critical customer-facing AI surfaces have a current disclosure UX attestation.
• Exception register comprehensive and reviewed monthly; zero exceptions past expiry un-escalated; Critical-tier missing go-live artifacts treated as blocking findings.
• Sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA as applicable) complete for in-scope assets.
• Regulatory or auditor inquiry evidence SLA (≤5 BD) met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation from MDM, SaaS-admin, browser-extension policy, own-built deployment, and edge-device telemetry; drive policy updates from monitoring signals and regulatory motion; and contribute to AI endpoint and transparency standards development.

Activities.

A) Continuous compliance attestation from MDM, SaaS-admin, and deployment signals. Evidence bundles auto-update from MDM app catalog events (AI app version update triggers IR recurrency check), SaaS-admin AI-feature events (M365 Copilot license change, Slack AI feature activation triggers inventory and tier re-check), browser-extension allowlist policy changes (new extension approved, existing extension permission-scope change triggers re-review), own-built AI surface deployment events (chatbot version release triggers disclosure UX attestation refresh, mobile AI app release triggers SR recency check), edge-device firmware events (on-device model update triggers TA snapshot recency check), identity-OAuth events (new AI service authorization triggers intake flag), and runtime-egress signals (new AI provider domain auto-opens intake). The attestation-generation pipeline produces a provenance-complete evidence pack for any endpoint AI asset, regulation-keyed (EU AI Act Art. 50 evidence pack, GDPR Art. 32/22 pack, ISO 42001 AIMS evidence set, sector-specific) or asset-keyed, within 3 business days. The currency SLO is ≤24 hours latency after a triggering event; completeness is ≥99% of active Critical/High assets.

B) Telemetry-driven policy refresh and regulatory-motion tracking. Operate a quarterly policy-refresh cycle driven by ML-Endpoints detection trends (which endpoint AI violation classes are rising, unauthorized extensions, productivity AI data-exposure, chatbot prompt-injection events), IM-Endpoints incident learnings (which policy gaps created the incident conditions), tier-movement data (which endpoint AI archetypes are growing fastest and at what risk level), and external regulatory and standards updates (EU AI Act Art. 50 implementing acts, EDPB guidance on AI and consent, FTC AI disclosure guidance, US state AI transparency laws, COPPA amendments, sector-specific AI guidance from HHS / OCC / NYDFS / FDA). Refresh output is a versioned changelog for each of the three policies approved by Legal/Privacy and Security; EG-Endpoints training content updates within 30 days of any policy change; SM-Endpoints inventory archetypes and tier rubric are reviewed for needed updates. A regulatory-motion tracker maintains a log of open regulatory instruments with expected effective dates, mapped to the policy each will affect; the working group reviews quarterly.

C) Standards contribution and external engagement. Participate in AI endpoint and transparency standards forums, EU AI Act Art. 50 implementing acts consultations, GDPR EDPB AI guidance rounds, NIST AI RMF Playbook working groups, OASIS conversational AI standards, CSA AI Safety Initiative endpoint AI controls, OWASP MASVS mobile AI security, CIS Critical Security Controls AI-endpoint extensions, OpenSSF AI working groups, and sector regulators (HHS patient-facing AI guidance, NYDFS Part 500, FTC AI disclosure, FDA digital health AI). Contribute AI-endpoint-specific artifacts to public standards, disclosure UX reference patterns for chatbot and voice AI (Art. 50 implementation reference), browser-extension governance framework, SaaS AI feature enablement governance playbook, mobile AI app consent UX patterns, edge AI model-integrity verification reference. Target at least two substantive public comments or standards contributions per year on AI/HAI endpoint policy and transparency topics.

Outcome Metrics (L3).

Success Criteria.

• On-demand attestation pack generation inside 3 business days for any active AI/HAI endpoint asset; SLA met in last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High assets.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
• ≥2 substantive public regulatory or standards contributions per year on AI/HAI endpoint policy and transparency; external recognition documented.
• Zero material audit findings on AI/HAI endpoint controls in the last 12 months.

Common Pitfalls

Level 1. - Reusing the generic AUP and IT security policy without AI-specific clauses, no rule on personal-account prohibition for AI tools, no data-class restriction for AI prompts, no disclosure requirement for customer-facing chatbots; auditors cannot trace Art. 50 compliance to any artifact. - Intake gate applies only to net-new customer-facing products announced through product management, misses AI features enabled in productivity SaaS by SaaS admins, browser extensions installed by users, mobile AI apps downloaded from the app store, and edge AI devices provisioned by IT without product security review. - Compliance map lists frameworks but does not say which policy carries which regulation, an auditor asking "which policy covers EU AI Act Art. 50?" has to trace coverage manually and typically concludes it is untraceable. - Customer-Facing AI Endpoint Disclosure Policy written as a legal notice rather than an operational UX specification, product engineers cannot implement it; disclosures are invented per feature rather than standardized. - Browser-extension policy is a PDF list with no enforcement mechanism, extensions are on the "prohibited" list but IT has no technical control to block them on managed browsers. - Deployer-duty owner role not assigned, customer-facing chatbots go live with no named Art. 26 / Art. 50 responsible party; EU AI Act obligations are acknowledged in policy but operationalized in no artifact.

Level 2. - Tier-specific addenda published but disclosure UX review requirements never enforced, Critical customer-facing AI surfaces go live without accessibility audit or Art. 50 review because no one enforces the policy requirement. - Compliance evidence bundle is a folder of PDFs only the compliance team can navigate, a second reviewer cannot assemble the regulator pack without specialist help. - Disclosure UX attestation treated as a one-time go-live check, chatbot disclosure language goes stale after a model upgrade or UX redesign and nobody re-reviews until a regulator asks. - Sector-specific bundles treated as "covered by the general Art. 50 disclosure", COPPA parental consent mechanism or HIPAA patient-facing AI notice specifics are never operationalized. - Browser-extension allowlist reviewed once at program launch and then never again, vendor changes silently expand the data-egress surface.

Level 3. - Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the artifacts mean; the 3 BD SLO is met but a follow-up hearing is required. - Policy refresh is cadence-only, quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain what incident prompted which change. - External contributions are deadline-only comment letters rather than technical artifacts (disclosure UX reference patterns, governance frameworks) that implementing bodies use in guidance. - Contributed disclosure UX patterns published once and then go stale, external practitioners stop trusting them when they find patterns inconsistent with current Art. 50 implementing acts. - ROI narrative omits compliance cost-reduction evidence, the biggest L3 business case (lower audit preparation overhead, faster regulatory response, reduced Art. 50 enforcement exposure) is never measured or reported.

Practice Maturity Questions

Level 1. 1. Have you published and formally approved the three priority AI/HAI endpoint policies, Endpoint AI Acceptable Use Policy, AI Browser-Extension Policy, and Customer-Facing AI Endpoint Disclosure Policy, with archetype-specific controls, data-class restrictions, and a deployer-duty owner requirement, and is there a one-page compliance map tying each priority requirement (EU AI Act Art. 50/26/9/Annex III, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, HIPAA/PCI-DSS/FERPA/COPPA) to the specific policy that carries it? Evidence: published policy set, approval signatures, and one-page compliance map. 2. Is the intake gate operational with a per-archetype artifacts checklist, a required disclosure UX review for customer-facing AI surfaces, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months have a gate record (100% for Critical/High)? Evidence: intake queue export reconciled against SM-Endpoints inventory. 3. Are ≥95% of managed-endpoint users covered by a current-year Endpoint AI AUP acknowledgment, and does every own-built customer-facing or decision-affecting AI endpoint surface in production have a named deployer-duty owner logged in the SM-Endpoints inventory with a disclosure UX record on file? Evidence: LMS attestation report and inventory column showing deployer-duty owners and disclosure UX records.

Level 2. 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Endpoints L2 rubric), and do Critical customer-facing AI surfaces carry explicit executive plus privacy-officer sign-off at go-live with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and current disclosure UX attestation? Evidence: tier addenda, gate records showing dual sign-off, and a sample evidence bundle for a Critical asset. 2. Is the compliance evidence bundle continuously maintained for every Critical/High asset with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days, including a current disclosure UX attestation for all Critical customer-facing AI surfaces? Evidence: evidence-registry staleness report and last inquiry-response log. 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing go-live artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA as applicable) complete for in-scope assets? Evidence: exception register, monthly review minutes, and sector-bundle completeness report.

Level 3. 1. Does a continuous attestation pipeline auto-update evidence bundles from MDM events, SaaS-admin AI-feature signals, browser-extension policy changes, own-built AI surface deployment events, and edge-device firmware events, with attestation currency ≤24h latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High assets continuously attested? Evidence: pipeline architecture, SLO dashboard, currency and completeness metrics. 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Endpoints detection trends + IM-Endpoints incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? Evidence: most recent policy changelog with rationale entries citing telemetry or regulatory source. 3. Does the program contribute ≥2 substantive public comments or standards artifacts per year on AI/HAI endpoint policy and transparency topics (EU AI Act Art. 50 implementing guidance, GDPR EDPB AI guidance, NIST AI RMF Playbook, OASIS, CSA, OWASP MASVS, CIS, OpenSSF AI, sector regulators) with documented external recognition? Evidence: contribution log with publication links and recognition citations.

16. Education & Guidance (EG)

Practice Overview

Objective: Build the AI-assurance literacy every managed-endpoint user needs when interacting with AI/HAI-enabled endpoint tools and the practitioner skills the smaller population performing endpoint AI reviews, customer-facing AI security assessments, mobile AI security testing, and edge AI threat modeling must have, with shadow AI on endpoints awareness as the primary L1 cultural outcome.

Description: EG-Endpoints covers three audiences. The first is the entire managed-endpoint user population, employees and contractors who use AI tools on laptops, mobile devices, and browsers; they need endpoint AI literacy covering what the seven endpoint AI archetypes are, what the Endpoint AI AUP requires, what data must not flow into AI tools, how to recognize that a productivity SaaS feature has quietly enabled AI capabilities, what AI browser extensions are sanctioned, and how to disclose AI tools they have already installed. The second is the practitioner population, endpoint security engineers, IT administrators managing AI-capable MDM and browser policies, product security engineers reviewing own-built chatbots and mobile AI apps, and edge/IoT engineers building on-device AI, who need deep, hands-on skills covering EDR detection of AI-specific data-egress patterns, browser-extension review methodology, customer-facing chatbot threat modeling against the HAI TTPs (EA / AGH / TM / RA), EU AI Act Art. 50 disclosure UX review, mobile AI permission scope assessment, and edge AI model-integrity verification. The third is the shadow-AI-on-endpoints awareness campaign, a sustained effort to surface AI tools employees and teams have already adopted outside governance.

Context: Endpoint AI literacy gaps are distinct from classic endpoint security training gaps. An employee who knows not to click suspicious email attachments will still paste customer PII into a productivity AI chatbot if no one has explained that the chat goes to a vendor AI model that may train on it. A browser-extension review that passes classic security checks (no malware signature, established publisher) will miss an AI extension that silently reads all form field content and sends it to an external AI API. A product security engineer trained in mobile OWASP will catch insecure storage and network issues but will not recognize the consent and disclosure gaps that make a mobile AI feature non-compliant with EU AI Act Art. 50. An IoT engineer who has hardened device firmware will not think about on-device model integrity unless someone has taught them to look for it. Without a deliberate EG practice targeted at these endpoint AI-specific gaps, endpoint AI risk surfaces late, at data-loss incident time, in regulatory enforcement, or in a customer complaint about an undisclosed AI interface.

Maturity Level 1

Objective: Deliver foundational endpoint AI literacy to ≥95% of managed-endpoint users and role-based practitioner training to 100% of the endpoint AI reviewer population, with an active shadow-AI-on-endpoints awareness campaign.

Activities.

A) Ship endpoint user AI-assurance literacy training. A single short course (≤20 minutes) every managed-endpoint user takes on hire and refreshes annually, tied to the Endpoint AI AUP attestation from PC-Endpoints L1. Content covers what the seven endpoint AI archetypes are with concrete examples from the org's own inventory (the coding assistant on the engineering laptop, the AI browser extension that summarizes pages, the customer support chatbot on the website, the voice AI interface in the mobile app, the M365 Copilot feature that just appeared in Teams, the mobile AI app the sales team is using, the kiosk running facial recognition at the front desk); the Endpoint AI AUP in five rules (use sanctioned tools; no personal accounts for work AI; what data must not go into AI tools, regulated data, customer-confidential, source code, internal financial, draft communications about individuals; how to request approval for a new AI tool; how to disclose a tool already in use); the HAI TTPs in plain language (Excessive Agency, the endpoint AI can do more than it should; Agent Goal Hijack, injected content from a document, page, or chat redirects the AI's goal; Tool Misuse, the endpoint AI's tools are invoked for attacker purposes; Rogue Agent, autonomous drift over long sessions), each with one concrete endpoint example; AI browser extensions safe-and-unsafe patterns (what makes an extension AI-capable and why that matters for data risk; how to check the allowlist; why "trusted publisher" does not equal "safe AI extension"); productivity AI quietly enabled in SaaS (how Copilot, Gemini, Slack AI, and Notion AI appear without explicit user action; what data is accessible in each context; how to flag unexpected AI feature activation to IT); mobile AI app risks specific to AI (microphone/camera/location consent disclosures; how to handle uncertainty about an AI app on a managed device); and the amnesty path (intake form accessible from the AUP, intranet, and IT helpdesk; no penalty for surfacing tools already in use). Delivery is an LMS module plus a one-page reference card pinned in enterprise Slack/Teams and the IT helpdesk portal plus a brief at all-hands when the program launches; no role gating at the workforce level.

B) Deliver role-based practitioner training for the endpoint AI reviewer population. A deeper module (approximately 2 hours) for the practitioner population only, endpoint security engineers, IT MDM/EDR administrators managing AI-capable policy, product security engineers for own-built customer-facing AI and mobile AI, and edge/IoT engineers. Completion is a prerequisite to approving endpoint AI intakes. Content covers the seven endpoint AI archetypes in depth, for each archetype, the unique threat surface, the relevant HAI TTPs, the key SR requirements, and the signals indicating elevated risk (a coding assistant with clipboard access to regulated-data directories; a browser extension with full page-content access on internal financial applications; a chatbot with action-taking capability on customer accounts; a voice AI interface without a disclosure UX; a mobile AI app requesting background microphone access without documented purpose); EDR detection of AI-specific data-egress patterns (how modern EDR surfaces AI tool egress to provider domains; what process execution and DNS/SNI patterns indicate a new AI tool in use; how to distinguish sanctioned AI tool egress from shadow AI or an AI browser extension operating outside policy); browser-extension review methodology (manifest.json permissions, content-script scope, background service worker network calls, declared API endpoints; Chrome Enterprise admin reports; how to assess data-class risk per extension using the SM-Endpoints rubric); customer-facing chatbot threat modeling applying the HAI TTP lens to own-built conversational AI (prompt injection via user input, AGH; excessive agency when the chatbot has backend action capability, EA; rogue agent drift in multi-turn conversations, RA; tool misuse if the chatbot calls internal APIs, TM; customer-data-egress risk; Art. 50 disclosure UX review methodology, what a compliant disclosure looks like vs. one buried in terms; accessibility check; sector overlay); mobile AI permission scope assessment (iOS entitlements, Android manifest permissions; on-device vs. cloud processing distinction; consent and disclosure UX testing; OWASP MASVS mobile AI requirements); edge AI model integrity and on-device inference threats (model substitution attack patterns; hash verification and signing; firmware review when a model is bundled in firmware; edge device identity and authentication); the priority compliance map in practice (given an archetype, which requirements apply and where the evidence lives, what a regulator will ask about an own-built customer-facing chatbot); and a calibration exercise scoring three sample endpoint AI intakes independently with instructor-facilitated debrief on tier assignment, TTP identification, SR gap list, and disclosure UX adequacy.

C) Run the shadow-AI-on-endpoints awareness campaign. An always-on communications program that makes it uncomfortable for AI tools and AI-feature surfaces to remain hidden and easy for employees to surface them. Launch moment, executive sponsor message naming shadow AI on endpoints as a real current risk, announcing the amnesty window, and publishing the sanctioned-AI-tool catalog with explicit framing that the program is an enabler, not a surveillance program. Recurring monthly short content, a newly sanctioned AI tool and what it can be used for; a reminder of what data must not go into AI prompts; an anonymized story of a shadow AI disclosure that led to a fast approval (positive reinforcement); an external incident about AI browser extensions or productivity AI data-exposure reframed as "this is why we track this." A "Has your SaaS AI changed?" series, periodic call-outs when major SaaS vendors (Microsoft, Google, Slack, Notion) roll out new AI features, with clear instruction on whether the features are already covered, require IT approval, or are in review, so users do not have to wonder whether the new Copilot feature in their Teams is sanctioned. Shadow AI disclosure path visibility, the disclosure path (intake form, IT helpdesk channel, direct MDM enrollment request) linked from the AUP, IT helpdesk portal, engineering channel pins, and onboarding checklist; disclosure must be as easy as the tool itself was to install. A feedback channel for employees to report AI tools seen in use, nominate AI tools for the sanctioned catalog, or ask whether a specific tool or extension is approved (nominations triaged and acknowledged within 5 BD). Customer-facing AI disclosure awareness micro-content for product and engineering teams shipping own-built AI surfaces, what Art. 50 requires in plain language, what a compliant disclosure UX looks like vs. what auditors find non-compliant, how to submit a disclosure UX specification at intake. Campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1).

Success Criteria.

• Workforce endpoint AI literacy module launched; ≥95% current-year completion sustained for managed-endpoint users.
• Practitioner training launched, completion gated on intake-approval permissions, covering all seven archetypes, and reviewer calibration drift inside target for two consecutive quarters.
• Shadow-AI-on-endpoints awareness campaign running with at least monthly content cadence and measurable attribution.
• Customer-facing AI disclosure awareness content deployed for every team shipping own-built AI surfaces in production.
• Training content owner named; content updated within 30 days of any change to policies, archetypes, or compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real endpoint AI intake cases, deliver channel-specific tracks for developer-endpoint, customer-support AI, mobile, and edge practitioners, and run seasonal shadow-AI-on-endpoints campaigns tied to SaaS release cycles and hiring periods.

Activities.

A) Scenario-based reviewer training from real endpoint AI intakes. Build a scenario library from anonymized real endpoint AI intake cases from the org's own queue; each scenario includes the as-submitted archetype description, the original reviewer decisions (tier, TTP identifications, SR gaps, disclosure UX adequacy), any reviewer disagreement, and the resolved outcome after calibration or post-launch review. Organize scenarios per archetype (chatbot, mobile AI app, browser extension, productivity AI, edge AI) and per TTP cluster (AGH-heavy for chatbots, EA-heavy for action-taking AI, data-egress-heavy for browser extensions, Art. 50-gap-heavy for customer-facing surfaces). Run paired calibration exercises in which two reviewers independently score the same scenario, with instructor-facilitated debrief on tier delta, TTP-identification delta, SR gap differences, and disclosure UX adequacy assessment. Weight curriculum to tier: Critical-tier customer-facing chatbot and mobile AI scenarios dominate advanced modules; Low-tier developer coding assistant scenarios streamline fast-track calibration. Practitioners graduate by running three live endpoint AI intakes end-to-end with a senior-reviewer shadow and producing a passing TA snapshot, SR REM, and (for customer-facing surfaces) a disclosure UX assessment record.

B) Channel-specific practitioner tracks. Deliver distinct training tracks for practitioners working in specific endpoint AI channels. The developer-endpoint AI track covers coding assistant deployment, AI IDE extensions, AI-augmented build tools on developer laptops; data-class risk of source code and internal API keys entering AI backends; MDM policy enforcement for AI developer tools; EA and TM TTPs in agentic coding assistant contexts (tools that can write files, run commands, make API calls); SR requirements for developer-only vs. broader deployment scope. The customer-support AI track covers own-built customer support chatbots and conversational UIs; AGH via customer-supplied injection through chat input; Art. 50 disclosure UX review methodology; customer-data-egress risk when chat sends interaction to a vendor AI model; action capability in support AI (ticket creation, account lookup, refund initiation) and EA/TM implications; customer-facing AI incident response patterns. The mobile AI track covers own-built mobile app AI features and vendor mobile AI assistants on managed mobile; iOS/Android permission scope review for AI capabilities (microphone, camera, location, contacts, device files); OWASP MASVS mobile AI requirements; on-device vs. cloud processing architectures; Art. 50 consent UX patterns for mobile; MDM mobile app governance; RA in persistent on-device AI. The edge AI track covers kiosks, IoT devices, embedded on-device inference; on-device model identity and integrity verification; model substitution attack patterns; edge device identity and authentication; firmware review methodology for AI model components; physical access threat surface; data-minimization by design for sensor and biometric-adjacent edge AI. Each track is paired with the SA reference pattern for the relevant archetype. Required for any practitioner reviewing a Critical or High-tier endpoint AI asset in the applicable channel; target ≥1 trained practitioner per Critical/High-tier asset.

C) Seasonal, behavior-driven shadow-AI-on-endpoints campaigns. Tie campaigns to observed shadow endpoint AI risk windows: major SaaS vendor AI feature rollouts (M365 Copilot expansion, Workspace Gemini rollout, Slack AI general availability, sudden large-population AI enablement that bypasses existing intake); device provisioning cycles (new device deployment means new AI tool installs without prior IT review); hiring surges (new employees arrive with AI tools already on personal devices that transfer to managed enrollment); post-external-incident moments (a public browser-extension data-exposure or chatbot data-leak incident creates a teachable window). Each campaign carries a pre-measured behavior target (for example, "reduce unapproved AI browser extension presence on managed endpoints by 40% in Q2" or "increase intake submissions before feature-flag launch by 25% in Q3") and a post-campaign measurement. Amnesty windows run alongside campaigns; disclosure volume and source attributed to campaign channels. Campaigns missing behavior targets by more than 20% are redesigned by the program sponsor.

Outcome Metrics (L2).

Success Criteria.

• Scenario library of ≥30 real-sourced endpoint AI intake cases across archetypes; reviewer calibration drift inside target for two consecutive quarters.
• Channel-specific training tracks (developer-endpoint AI, customer-support AI, mobile AI, edge AI) delivered; ≥1 trained practitioner per Critical/High-tier asset.
• ≥2 behavior-driven campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit behavior target.
• Training content refresh cadence met; ≥80% of content updated in last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the endpoint AI curriculum and reviewer rubric as industry-shared artifacts, and contribute to emerging endpoint AI and mobile AI security certification pathways.

Activities.

A) Externalize the curriculum, scenario library, and reviewer rubric. Publish the workforce endpoint AI literacy module (learning objectives, assessment questions, reference-card template covering the seven archetypes and shadow AI disclosure), the practitioner role-based training curriculum (module outlines, channel-track coverage matrix, per-archetype reviewer job aids for chatbot, mobile AI, browser extension, edge AI), the anonymized scenario library (scenario format, per-archetype examples including Art. 50 disclosure UX review scenarios, calibration debrief format), and the reviewer rubric (tier-assignment criteria using the seven SM-Endpoints L2 rubric dimensions, TTP-identification scoring, SR-gap-list completeness scoring, disclosure UX adequacy assessment criteria) under a permissive license or as a consortium deliverable through CSA AI Safety Initiative, OWASP MASVS, OASIS conversational AI, CIS Critical Security Controls, or the applicable sector ISAC. Accept community contributions; flow changes back into internal content within 30 days. Track adoption via citations in external publications, forks, downloads, and direct adoption acknowledgment.

B) Continuous live calibration. Run monthly calibration rounds: a current anonymized endpoint AI intake case sampled from the program's live queue is shared with the reviewer cohort; each reviewer independently scores tier, TTPs, top three SR gaps, and (for customer-facing surfaces) disclosure UX adequacy; drift is reported to the program sponsor. Individual reviewer drift is a development signal, not a performance metric, reviewers with persistent drift on specific archetype channels (consistently under-scoring edge AI model-integrity findings, missing Art. 50 disclosure adequacy gaps) 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) Endpoint AI certification contribution. Contribute to AI-engineering and endpoint AI security certification pathways as they emerge, CSA AI Safety, ISACA AI Audit / AI Risk certificates, OWASP MASVS examinations, sector-specific ISAC credentials relevant to chatbot security and mobile AI security, OpenSSF AI Practitioner pathways. 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-built or consumed endpoint AI observations, novel browser-extension prompt-injection patterns, mobile AI over-privileged tool-use observations, edge device model-substitution technique instances, minimum one per year where novel observations exist. Target ≥2 substantive contributions per year to industry endpoint AI curriculum or certification working groups.

Outcome Metrics (L3).

Success Criteria.

• Curriculum, scenario library, and reviewer rubric published externally with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters; calibration results feeding the scenario library continuously.
• ≥50% of Critical-tier endpoint AI reviewers credentialed where credentials exist.
• ≥2 substantive contributions to industry endpoint AI certification or curriculum per year.
• ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist.

Common Pitfalls

Level 1. - Workforce training covers classic "don't click suspicious links" but not the AI-specific endpoint risks (pasting regulated data into AI prompts, productivity AI quietly accessing sensitive files, browser extensions reading form content and sending it to external AI APIs), the endpoint AI literacy gap remains entirely open. - Practitioner training is a one-hour "AI security overview" rather than a hands-on module covering the seven endpoint archetypes, EDR-based AI-egress detection, browser-extension review methodology, chatbot threat modeling, mobile AI permission scope, and edge AI model integrity. - Reviewer training is optional, intake-approval permissions granted without training completion; calibration drift is never measured; two reviewers arrive at different tiers and different disclosure UX adequacy assessments for the same chatbot. - Shadow-AI-on-endpoints campaign launches once with a Slack message from IT, then goes silent, no monthly content, no attribution tracking, no amnesty path visibility. - Training is archetype-agnostic, "AI security" without distinguishing between a customer-facing chatbot (AGH / EA / Art. 50 disclosure) and a developer coding assistant (data-class restriction / personal-account prohibition); practitioners apply the wrong review lens. - Customer-facing AI disclosure awareness content never ships for product teams, engineers shipping chatbots have no mental model for Art. 50 UX requirements at implementation level; disclosures are invented per feature, inconsistent, and non-compliant.

Level 2. - Scenario library is built from invented examples rather than anonymized real intake cases, reviewers learn the shape of a textbook chatbot intake but not the actual edge cases that surface in the org's queue. - Channel-specific tracks are optional; endpoint AI practitioners skip them and then produce reviews that miss archetype-specific controls in DR, the mobile AI reviewer misses the MASVS consent UX requirement; the edge AI reviewer misses the model-integrity verification step. - Campaigns launched without a pre-measured behavior target, "shadow AI awareness" claimed as success without data on whether unapproved browser extension presence decreased or intake submissions rose. - Content "refreshes" are cosmetic, module covers updated, scenario descriptions wordsmithed, but the browser-extension review checklist is not updated after a major Chrome Enterprise Admin policy change; practitioners use outdated methodology. - Calibration drift is measured but not acted on, reviewers with persistent drift on edge AI model-integrity scenarios never receive targeted coaching; the calibration exercise becomes a quarterly box-check.

Level 3. - External publication without ongoing maintenance, other organizations find a scenario library that references outdated Art. 50 implementing acts and stop trusting the program; citations dry up. - Credentialing becomes performative, reviewers pursue credentials that do not map to the org's actual endpoint AI tier-treatment rubric; credential acquisition is celebrated but calibration drift on real intakes stays unchanged. - Live calibration becomes a gotcha rather than a development signal, reviewers game the monthly exercise and improve calibration scores without improving actual intake quality for novel archetype combinations. - Contributions to industry working groups do not loop back, what is published externally drifts from internal practice; practitioners cite the external artifact and contradict the internal rubric. - ATLAS contributions are aspirational but never actually submitted, the org observes novel browser-extension AI exfiltration or mobile AI over-privileged tool-use patterns but does not complete the ATLAS submission process.

Practice Maturity Questions

Level 1. 1. Have all managed-endpoint users completed a current-year endpoint AI literacy course covering the seven endpoint AI archetypes (with org-specific examples), the HAI TTPs (EA / AGH / TM / RA) plus prompt injection and productivity-AI data-exposure patterns, the Endpoint AI AUP rules (personal-account prohibition, regulated-data restrictions, browser-extension hygiene), and the shadow AI disclosure path, with ≥95% completion and content updated within 30 days of any policy or archetype change? Evidence: LMS completion report, content change-log, and the most recent literacy module. 2. Has the endpoint AI reviewer population (endpoint security engineers, IT MDM/EDR administrators, product security engineers for own-built surfaces, mobile AI engineers, edge AI engineers) completed role-based training covering all seven endpoint archetypes, EDR AI-egress detection, browser-extension review methodology, chatbot threat modeling (AGH/EA/TM/RA TTPs and Art. 50 disclosure UX review), mobile AI permission scope assessment (OWASP MASVS), and edge AI model-integrity verification, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 TTP misclassifications per sample for two consecutive quarters? Evidence: practitioner curriculum, permission-gating record, and calibration-exercise results. 3. Is a shadow-AI-on-endpoints 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 shadow AI disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-tool catalog grows? Evidence: campaign content calendar, channel-attribution report, and amnesty disclosure trend.

Level 2. 1. Is there a scenario library of ≥30 anonymized real endpoint AI 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 TTP misclassification per sample for two consecutive quarters? Evidence: scenario library index and quarterly Critical-tier calibration drift report. 2. Have channel-specific practitioner tracks (developer-endpoint AI, customer-support AI, mobile AI, edge AI as applicable) been delivered to ≥1 practitioner per Critical/High-tier asset in each applicable channel, with team-level training coverage tracked in the SM-Endpoints inventory? Evidence: track rosters reconciled against the inventory's Critical/High asset list. 3. Are shadow-AI-on-endpoints campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days? Evidence: campaign plans with pre/post measurements and content-refresh changelog.

Level 3. 1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CSA AI Safety Initiative, OWASP MASVS, OASIS, CIS, or sector ISAC) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days? Evidence: external publication links, adoption telemetry, and internal update changelog. 2. Is a monthly live calibration cadence operating (anonymized endpoint AI intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier endpoint AI reviewers hold an external AI-assurance or endpoint-AI credential where one exists? Evidence: calibration log, scenario-library update trail, and credential registry. 3. Does the program contribute ≥2 substantive artifacts per year to industry endpoint AI certification or curriculum working groups, and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel endpoint AI observations exist? Evidence: contribution log with acceptance confirmations and the ATLAS submission record.

17. Threat Assessment (TA)

Practice Overview

Objective: Build and maintain a reusable threat library for the AI/HAI-enabled endpoints and user-facing AI interfaces the organization deploys or procures, one archetype-level threat model per endpoint AI type, so every endpoint AI entering the SM inventory produces a threat snapshot in minutes rather than a blank-page exercise.

Description: TA-Endpoints catalogs the threats specific to AI/HAI interfaces the organization deploys on managed endpoints and customer-facing surfaces. At L1 the library covers one threat model per endpoint archetype, 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, mapped to HAIAMM's HAI-specific TTPs (EA, AGH, TM, RA), to MITRE ATLAS tactics (TA0001–TA0014) and techniques (notably AML.T0024 inference exfiltration and AML.T0051 LLM prompt injection), and to OWASP LLM/Agentic Top 10, OWASP Browser-Extension Security Top 10, and OWASP MASVS where applicable. Each deployment registered in the SM inventory generates a threat snapshot by pulling the archetype model and adding deployment-specific deltas: specific tool list, specific data classes accessible, deployment tier, user population, and Art. 50 disclosure obligation. L2 layers per-deployment deep models for Critical-tier cases (customer-facing chatbots, customer-data-handling AI assistants, sensor-rich mobile and edge AI) and red-teams the library quarterly against real deployments. L3 automates library maintenance from telemetry and external feeds and contributes discovered TTPs back to MITRE ATLAS, AVID, OWASP MASVS/Browser-Extension Top 10, and CSA endpoint working groups.

Context: Endpoint AI introduces failure modes that classic endpoint-security threat modeling was never designed to enumerate, confidential data egressing to vendor models through developer paste behavior, prompt injection arriving through opened files or browser page content reaching an assistant's context window, silent SaaS-AI feature enablement giving a tenant-wide LLM access to all documents, multi-modal injection via crafted images or audio, mobile on-device model swap, and edge-device firmware/model integrity attacks. These are first-party risks owned by IT, security, endpoint engineering, and product teams that deploy or configure the AI. TA-Endpoints closes the gap by making endpoint-AI-specific threats a first-class library, tied to ATLAS technique IDs so the walk from attacker capability to endpoint exposure is concrete, not narrative, and by tagging every archetype threat to the HAI TTP (EA/AGH/TM/RA) it activates so reviewers can triage which threats matter for a specific deployment's failure modes.

Maturity Level 1

Objective: Build the AI/HAI endpoint archetype threat library, integrate a threat snapshot into every SM intake, and ensure every endpoint AI's threat surface is documented before deployment approval.

Activities.

A) Build the AI/HAI endpoint archetype threat library. Author one threat model per endpoint AI archetype. Each is concise (target two pages), explicitly scoped to AI/HAI interfaces the organization deploys or procures on endpoints and customer-facing surfaces, and maps threats to HAI TTPs, ATLAS tactic IDs, applicable OWASP references (LLM/Agentic Top 10, MASVS, Browser-Extension Security Top 10), and the PC-Endpoints priority compliance map. The seven archetypes to cover at L1: AI assistant/copilot on managed endpoint (desktop or IDE-integrated assistant calling a vendor LLM API and accessing local filesystem, clipboard, or developer tooling); browser-based AI tool (extension or web AI interface reading page content, DOM, cookies, or form data); chatbot/conversational UI (customer-facing or employee-facing conversational interface); multi-modal AI interface (accepts image, audio, or video inputs); AI-augmented productivity (SaaS-AI features layered on productivity, CRM, or collaboration suites); mobile AI app (native or hybrid mobile application with on-device or cloud-based AI features and sensor access); edge AI device (physical device running AI inference locally with limited remote management and physical-access exposure). Per-archetype content covers EA patterns (assistant silently exfiltrating data within its tool scope, extension scope wider than any individual user permission, SaaS-AI inheriting full data scope), AGH patterns (prompt injection via opened files for assistants, tainted page content for browser tools, user-turn injection for chatbots, image/audio injection for multi-modal, AML.T0051), TM patterns (assistant invoking endpoint tools maliciously, browser-extension DOM-write abuse), and RA patterns (deepfake acceptance in multi-modal, on-device model swap for mobile, firmware/model tampering for edge). Each archetype model documents the full ATLAS tactic walk (TA0001 Reconnaissance through TA0014 Impact) with techniques selected or excluded with rationale, anchoring AML.T0024 (Exfiltration via ML Inference API) for any path where org data reaches a vendor model and AML.T0051 for any injection path. Compliance linkage is explicit: EU AI Act Art. 50 (disclosure for customer-facing chatbots and conversational UIs), EU AI Act Art. 26 (deployer duties for high-risk uses), GDPR Art. 22 (automated decisioning safeguards), GDPR Arts. 6, 9, 28, 44–49 (data handling and biometric special-category obligations). Owner: named TA-Endpoints library steward; cadence: reviewed quarterly; versioned in a single location linked from every SM inventory record.

B) Produce a per-intake threat snapshot for every SM inventory registration. Bind TA into the SM intake flow, every new endpoint AI registration emits a threat snapshot before Sanctioned status is issued; Provisional-status deployments receive a snapshot within five business days. Snapshot contents (designed to fit one screen): which archetype(s) apply (a deployment may be composite, a SaaS productivity platform with an AI feature and a browser extension frontend is both AI-augmented productivity and browser-based AI tool); deployment-specific deltas over the archetype model covering SM-Endpoints tier, specific tool list or sensor access, specific data classes accessible, customer-data egress potential, and Art. 50 disclosure obligation; top-five threats for this deployment each with HAI TTP tag, ATLAS tactic ID, OWASP reference, and compliance linkage; controls already evident from the design or existing configuration vs. gaps for SR/SA follow-up; reviewer, date, and expiry (re-snapshot on new tool addition, permission scope change, model swap, data class change, or user population expansion). Time target: one business day per intake with the library available. Most threat content comes pre-written in the archetype model; the reviewer adapts rather than invents.

C) Author the shadow-endpoint-AI threat view. Unsanctioned endpoint AI, employees installing AI browser extensions on managed devices, SaaS-AI features silently enabled by workspace admins, AI assistant apps installed via personal stores on BYOD accessing org email, edge AI kiosks deployed by facilities teams without IT, has its own threat surface distinct from sanctioned deployments. The shadow-endpoint-AI threat document covers entry vectors (self-installed AI browser extensions with <all_urls> permissions on managed endpoints; SaaS-AI features silently enabled tenant-wide without security review; AI assistant apps on BYOD; edge AI kiosks deployed without IT involvement); elevated threats for shadow deployments (no threat snapshot, no SR requirements pack, no verified no-train assertion, Art. 50 obligations unreviewed, regulated data flowing to vendor models without DPA); specific failure modes (developer pasting customer PII into an unapproved AI assistant with training enabled; SaaS-AI with access to confidential M&A documents enabled tenant-wide; AI browser extension harvesting session cookies from internal applications); and detections available at L1 (MDM/UEM telemetry on unauthorized app/extension installs, network egress monitoring to AI provider domains, SaaS-admin audit logs on AI feature enablement, endpoint DLP alerts on regulated-data patterns in AI API calls). Output: a "Shadow Endpoint AI, Threat View" one-pager reviewed by the program sponsor and feeding the ML-Endpoints detection backlog and the IM-Endpoints triage playbook.

Outcome Metrics (L1).

Success Criteria.

• Seven archetype threat models published (AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device), each tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs (TA0001–TA0014) anchoring AML.T0024 and AML.T0051, applicable OWASP LLM/Agentic/MASVS/Browser-Extension references, and the PC-Endpoints priority compliance map.
• Threat snapshot gate live in the SM intake flow, 100% of newly Sanctioned endpoint AI deployments in the last 90 days have a snapshot attached before Sanctioned status is issued.
• Shadow-endpoint-AI threat view published, reviewed by the program sponsor, and feeding the ML-Endpoints detection backlog and the IM-Endpoints triage playbook.
• Named library steward and quarterly refresh cadence operating.
• ≥90% of active endpoint AI deployments in the inventory carry a current-year snapshot.

Maturity Level 2

Objective: Layer per-deployment deep threat models on top of archetype snapshots for Critical-tier deployments, integrate external AI endpoint threat intelligence, and red-team the threat library quarterly against novel real-world attack patterns.

Activities.

A) Per-deployment deep threat modeling for Critical-tier deployments. For every Critical-tier endpoint AI deployment in the SM inventory, produce a full per-deployment threat model that goes beyond the archetype snapshot. Coverage: deployment-specific attack trees including per-tool abuse paths for assistants, per-permission abuse paths for browser extensions, per-feature data-scope abuse for SaaS-AI, per-sensor abuse for mobile and per-uplink abuse for edge; an abuse-case catalog with named adversary archetypes (external attacker crafting adversarial inputs, malicious insider with access to the endpoint AI admin console, compromised SaaS-AI vendor, attacker with physical access to an edge device) with concrete attack narratives for this specific deployment; deployer-duty mapping covering EU AI Act Art. 26 obligations, Art. 50 disclosure obligations including disclosure-suppression risk for chatbots, and GDPR Art. 22 automated-decisioning safeguards where the deployment drives consequential decisions; and a full ATLAS tactic walk for the deployment with technique-level specificity across all 14 tactics. High-tier deployments receive archetype snapshot plus deployment-specific deltas and an ATLAS full tactic walk; no High-tier deployment remains on archetype-only. Refresh cadence: Critical semi-annual plus change-driven on tool addition, sensor change, model swap, scope change, or user population expansion; High annual plus change-driven.

B) External AI endpoint threat intelligence integration. Subscribe to and operationalize MITRE ATLAS updates (new technique additions and practitioner-submitted evidence relevant to endpoint archetypes), AVID new entries for techniques relevant to chatbots, browser extensions, mobile AI, and edge AI, OWASP LLM Top 10/Agentic Top 10 revisions and OWASP MASVS/Browser-Extension Security Top 10 updates, academic adversarial-ML venues (IEEE S&P, USENIX Security, NeurIPS ML Safety, ACM CCS) for early signal on novel multimodal injection, model-integrity attacks, and edge-device adversarial inputs, sector ISAC AI working groups for operationally observed attack patterns relevant to the org's industry and customer-facing AI surfaces, and CSA endpoint security working group outputs. Quarterly triage cadence determines which new items change the archetype library, change per-deployment models, or require updates to dependent SR or ST artifacts. Changes are change-logged and reviewed by the library steward and the IM backlog owner. Intel-to-library update lead time targets 30 days on Critical-impact items.

C) Red-team the threat library itself. Each quarter, ST-Endpoints runs an adversarial probe against an in-scope endpoint AI deployment using only the threat scenarios documented in the library for that archetype. Threats the exercise identifies that are not in the library are library gaps, not passing findings. Gap closure is a governance activity: every gap becomes a ticket with a named owner and an expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days. The gap rate per quarter trends down as the library matures. Gaps are also reviewed for SR and ST update implications, a threat absent from the library is also likely absent from a requirement and a test.

Outcome Metrics (L2).

Success Criteria.

• Per-deployment deep threat models live for 100% of Critical-tier and ≥90% of High-tier deployments, with refresh cadences (Critical semi-annual, High annual) met.
• External threat intel integrated with quarterly triage and a documented change-log; intel-to-library update ≤30 days on Critical-impact items.
• Quarterly red-team-the-library exercise operating; every gap carries a named owner and expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days.

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered endpoint AI TTPs back to MITRE ATLAS, AVID, OWASP MASVS/Browser-Extension Top 10, and CSA endpoint working groups.

Activities.

A) Telemetry-driven library updates. Wire ML-Endpoints detection alerts (patterns that do not map to any existing library entry surface as candidate new threats), IM-Endpoints post-incident review records (the incident's ATLAS tactic walk is auto-ingested), external feeds (ATLAS technique additions, AVID new entries, OWASP LLM/MASVS/Browser-Extension revision drafts, sector-ISAC AI advisories, CSA endpoint AI security updates), and academic publication scanning (weekly digest of adversarial-ML, multimodal-attack, and edge-AI-security papers) into an auto-proposal pipeline. Human curators approve, reject, or defer each auto-proposal. The change-log is machine-readable; downstream SR and ST artifacts subscribe to the change feed and receive update-required notifications when a threat they reference changes. Target: ≥60% of library changes auto-proposed; lead time from signal to update ≤14 days.

B) Industry contribution. Contribute emerging first-party-observed TTPs, novel multimodal injection patterns, edge-device model integrity attacks, browser-extension DOM-injection chains, SaaS-AI feature-scope-inheritance exploitation, mobile on-device model swap variants, to MITRE ATLAS following ATLAS evidence-and-provenance requirements; to OWASP MASVS AI extensions and OWASP Browser-Extension Security Top 10 revision cycles with real-world telemetry evidence; to AVID via structured disclosure submissions; and to CSA endpoint AI security working group with archetype threat models as input to endpoint AI security guidance. Target: at least four substantive contributions per year, quality-graded and legally vetted before submission, every contribution anonymized.

C) Shared threat-model artifacts. Publish anonymized archetype threat models (scrubbed of org-specific tool names, vendor names, and deployment details) under a permissive license for peer-org adoption. Host or co-host at least one industry tabletop per year tied to the library, ATLAS practitioner table, OWASP AI chapter, CSA endpoint working group, or sector ISAC AI working group.

Outcome Metrics (L3).

Success Criteria.

• Library auto-update pipeline operating with ≤14-day lead time from signal to update; ≥60% of changes auto-proposed; machine-readable change-log consumed by downstream SR and ST.
• ≥4 industry contributions per year; ≥2 recognized in external artifacts (ATLAS merge, AVID entry, OWASP revision, CSA guidance).
• Anonymized archetype threat models published under permissive license with tracked peer-org adoption.
• Industry tabletop hosted or co-hosted in last 12 months.

Common Pitfalls

Level 1. - Threat models describe endpoint AI performing security monitoring rather than describing the endpoint AI interface as the subject being assessed, the library catalogs what AI tools do for security rather than what threats face the endpoint AI the org deploys. - Archetype library covers chatbots and AI assistants but omits browser extensions and edge AI devices, the two archetypes with the most direct exposure to permission-abuse and physical-access threats remain without threat models. - Threat snapshot is completed at deployment approval and never refreshed, a SaaS-AI feature that gains new data-scope access or an AI assistant whose tool list expands does not trigger a re-snapshot. - ATLAS tactic walk is performed for narrative completeness but no technique IDs are assigned, the walk produces prose, not structured references that ST and IR can act on. - HAI TTPs (EA/AGH/TM/RA) are listed in the library header but not tagged per-threat, reviewers cannot triage which threats matter for a specific endpoint archetype's failure modes. - Library steward is unnamed, the quarterly refresh calendar item is no one's job and the library drifts from current endpoint AI attack research within two quarters.

Level 2. - "Per-deployment deep model" is the archetype snapshot with the deployment name swapped in, no deployment-specific tool list analysis, no data-class exposure consequence, no user-population risk assessment; the depth is cosmetic. - External intel is subscribed but never triaged, ATLAS update emails and OWASP MASVS revision drafts accumulate unread; the library is frozen at L1 publication while the threat landscape evolves. - Red-team-the-library exercise is a threat-hunting session that adds entries to a finding log but never cross-checks findings against the library, gaps are never surfaced because the comparison was never made. - Critical-tier accepted gaps from the library red-team lack owners or expiry dates, gap backlog grows without accountability. - Deep modeling stops at Critical tier; High-tier deployments (customer-data-handling AI assistants, sensor-rich mobile AI) remain on archetype-only snapshots despite carrying regulated data.

Level 3. - Auto-proposal pipeline accepts signals without curation, false-positive ML-Endpoints detections pollute the library with phantom threats; downstream SR and ST artifacts generate incorrect requirements and tests. - Contributions to MITRE/AVID/OWASP/CSA are observer submissions (comments, conference talks) rather than technical artifacts with evidence that produce substantive change. - Published anonymized archetype models are not maintained after release, external adopters build on a stale version while the internal library has advanced; the divergence becomes visible when discrepancies are cited publicly. - Telemetry-driven update loop fires on every minor endpoint configuration change; endpoint teams disable the telemetry feed to stop the noise rather than tune signal sensitivity.

Practice Maturity Questions

Level 1. 1. Are there published, versioned threat models for all seven endpoint AI archetypes, AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device, each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs anchoring AML.T0024 and AML.T0051, applicable OWASP LLM/Agentic/MASVS/Browser-Extension references, and PC-Endpoints compliance items, with a named library steward and documented quarterly refresh cadence? Evidence: TA library with seven versioned archetype documents and a named owner record. 2. Does every endpoint AI deployment entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), deployment-specific deltas (tool list, data classes accessible, tier, user population, Art. 50 disclosure obligation), top-5 threats with HAI TTP tags and ATLAS tactic IDs, and gaps for SR/SA follow-up, with 100% of newly Sanctioned deployments carrying a snapshot in the last 90 days? Evidence: SM intake tickets with snapshot attachments dated within intake SLA. 3. Is there a published shadow-endpoint-AI threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors, elevated threat scenarios for unsanctioned endpoint AI deployments, and the specific detections (MDM telemetry, egress monitoring, SaaS-admin audit logs, endpoint DLP signals) used to surface them? Evidence: Dated threat view document with program-sponsor review record and links to ML-Endpoints and IM-Endpoints backlogs.

Level 2. 1. Does every Critical-tier endpoint AI deployment have a current-year per-deployment deep threat model (not an archetype snapshot) covering deployment-specific attack trees, an abuse-case catalog by adversary archetype, deployer-duty mapping (Art. 26, Art. 50, GDPR Art. 22), and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on tool additions, sensor changes, model swap, or scope expansion? Evidence: Per-deployment threat model documents dated within cycle with change-driven update records. 2. Is external AI endpoint threat intel (MITRE ATLAS, AVID, OWASP LLM/Agentic/MASVS/Browser-Extension, sector ISACs, academic adversarial-ML venues, CSA endpoint AI) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? Evidence: Quarterly triage meeting records and change-log entries with signal-to-update timestamps. 3. Do you run a quarterly red-team-the-library exercise that probes an in-scope endpoint AI deployment using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter? Evidence: Quarterly exercise artifacts with gap register showing owner assignments and closure dates.

Level 3. 1. Does the threat library auto-update from telemetry (ML-Endpoints detections, IM-Endpoints incidents) and external feeds (ATLAS, AVID, OWASP, CSA, academic) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? Evidence: Pipeline telemetry showing proposal rate and lead-time distribution; SR/ST subscription confirmation. 2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / OWASP MASVS / Browser-Extension Top 10 / CSA endpoint AI security, with at least two externally recognized in published advisory or standard revisions? Evidence: Contribution log with external recognition citations. 3. Are anonymized endpoint archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, OWASP AI chapter, CSA endpoint working group, sector ISAC AI working group) tied to the library? Evidence: License artifact, adoption tracking data, tabletop event record.

18. Security Requirements (SR)

Practice Overview

Objective: Translate the threats from TA-Endpoints and the policies from PC-Endpoints into a reusable Requirements Pack for AI/HAI-enabled endpoints and user-facing AI interfaces the organization deploys, a base set plus per-archetype deltas, so every deployment entering the managed estate carries a testable Requirements-Evidence Map rather than a blank slate.

Description: SR-Endpoints authors a small, archetype-keyed AI/HAI Endpoints Requirements Pack: one base requirement set that applies to every endpoint AI deployment, plus per-archetype deltas for 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, and edge AI device. Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every deployment reaching SM intake carries a Requirements-Evidence Map (REM) linking each applicable pack requirement to current evidence, accepted gaps (with a named owner and expiry date), and compensating controls. Downstream practices (SA, DR, IR, ST) inherit the REM rather than re-deriving requirements per deployment. Cross-Vendors-domain linkage is explicit: endpoint AI sourced from a vendor inherits the Vendors-domain REM for vendor-level controls; the Endpoints REM covers endpoint-local controls (DLP at endpoint, MDM-enforced extension allowlist, attestation at boot) and cross-references the Vendors REM.

Context: Without a shared requirements pack, each deployment review invents the acceptance bar from scratch. An AI assistant and a customer-facing chatbot receive inconsistent review. Browser extensions ship with <all_urls> permission because no requirement said otherwise. SaaS-AI features are enabled tenant-wide without intake. Mobile AI apps request every sensor permission without justification. EU AI Act Art. 50 disclosure obligations, Art. 26 deployer duties, and GDPR Art. 22 safeguards are not consistently verified because there is no shared traceability from regulation to requirement to evidence artifact. SR-Endpoints closes that gap with the minimum viable pack, not a checklist of 60 items, but the requirements that matter for every endpoint AI the org deploys, plus archetype-specific additions for chatbots, mobile AI apps, edge devices, and browser extensions.

Maturity Level 1

Objective: Publish the AI/HAI Endpoints Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every endpoint AI deployment.

Activities.

A) Author the base AI/HAI Endpoints Requirements Pack. The base pack applies to every endpoint AI deployment the org manages, regardless of archetype. Keep it to 20 or fewer base requirements at L1. Each requirement has: an ID, a statement, a rationale (threat tag from TA-Endpoints and compliance tag from PC-Endpoints), an evidence source, a test method, and an acceptance criterion. Minimum base categories: identity and auth, SSO and MFA on AI consoles and admin interfaces, managed-endpoint requirement for Critical-tier AI use, personal-account prohibition for org data, service-principal model for any endpoint AI tool with backend access; DLP at endpoint, DLP controls configured at the endpoint or network layer to block or alert on regulated-data paste into AI assistants, rules tuned for AI-specific patterns (code containing secrets, PHI, customer record exports), DLP alerting scoped to AI provider domains; browser extension allowlist with per-extension scope review confirming host-permission scope justified (no <all_urls> without documented necessity and compensating controls), page-content-read and DOM-write access justified; per-archetype data-class boundaries declaring which data classes may flow into each endpoint AI archetype; vendor no-train assertion verified at the admin-console or API level and re-verified on a documented cadence (not trusted from contract text alone); endpoint logging covering AI-tool use events, extension activations, and data-exfiltration alerts forwarded to SIEM; customer-facing AI disclosure (EU AI Act Art. 50) present and persistent on every chatbot or conversational UI session, not suppressible by system prompt or user request; mobile permission scope minimization with over-broad permissions blocked or exception-approved; local-model integrity verification for on-device models (signed artifacts verified at load time); edge device integrity (signed firmware and signed model, attestation at boot, physical-tamper detection where feasible); kill-switch/disable path documented and tested at least annually with activation SLA ≤4 hours; affected-persons rights surface (GDPR Art. 22) where the endpoint AI drives consequential decisions. Every base requirement is tagged to at least one TA-Endpoints archetype threat and at least one item from the PC-Endpoints priority compliance map.

B) Author per-archetype requirement deltas. Each archetype carries a short delta (three to eight additional requirements) reflecting the threat-specific obligations from TA-Endpoints's archetype threat models. The AI assistant/copilot delta covers quarterly admin-console no-train re-verification, tool allowlist published for any assistant with local file-system, shell, or external-API tool access, tool-scope minimization documented per tool (file-read scoped to declared directories, no file-write without explicit policy), per-session memory bounds documented, and audit log of assistant actions on endpoint retained and exportable. The browser-based AI tool delta requires per-extension scope review on file for every allowlisted extension (<all_urls> prohibited without exception), DLP integration verified for AI browser extensions, SSO enforcement for extension backend, and extension version pinned or update-channel controlled. The chatbot/conversational UI delta requires prompt-injection defense at the input edge, output filter deployed and tested against jailbreak and data-exfiltration probes, Art. 50 disclosure on every customer interaction (UX implementation reviewed and tested, disclosure persistent and not suppressible), escalation-to-human path documented and operational, rate-limit and abuse-detection controls, per-session memory bounds, and full prompt/completion logging with PII redacted per GDPR Art. 5. The multi-modal AI delta requires modality-specific input validation (image content moderation, voice biometric anti-spoof, deepfake detection where required by tier), output safety filters covering all modalities, cross-modal consistency check for high-stakes decisions, and biometric data handling documented under GDPR Art. 9 with lawful basis on file. The AI-augmented productivity (SaaS-AI) delta requires SaaS-admin governance for AI-feature enablement (intake required before enabling any AI feature at the tenant level), per-feature data-scope review, conditional enablement policy, and admin audit of who enabled what AI feature when. The mobile AI app delta requires signed app and signed local model, permission audit on file for every deployed mobile AI app, on-device model integrity attestation, secure-enclave requirement for sensitive operations, and opt-in for sensor access (camera, microphone, location, health data). The edge AI device delta requires signed firmware and signed model with attestation at boot confirmed by backend, physical-tamper detection documented and tested where feasible, uplink traffic signed and encrypted, and remote-disable mechanism tested at least annually.

C) Wire the pack into the SM intake gate, establish cross-Vendors-domain REM linkage, and produce a REM per deployment. Every deployment approved for the managed estate carries a REM. Each applicable pack requirement is marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable with justification. Each Met row cites specific evidence: MDM policy screenshot, admin-console state, extension scope review artifact, DLP rule configuration, kill-switch test result, Art. 50 UX screenshot, model-signing verification log, or attestation record. Each Gap-accepted row names a compensating control, a named owner, and a re-review date (maximum 90 days at L1) with residual-risk rationale accepted by the named sponsor. Cross-Vendors-domain REM linkage: for endpoint AI sourced from an external vendor, the Endpoints REM cross-references the Vendors-domain REM for that vendor; vendor-level controls (DPA, no-train contract clause, vendor security assessment) live in the Vendors REM; endpoint-local controls (DLP at endpoint, tool allowlist, admin-console verification, attestation) live in the Endpoints REM. A change in the Vendors REM (vendor DPA updated, no-train clause removed) triggers a flag on the corresponding Endpoints REM. Material changes, new tool access granted, permission scope expanded, model swap, new user population, new data class accessible, trigger REM re-review before the change ships.

Outcome Metrics (L1).

Success Criteria.

• Base pack plus seven archetype deltas published, tagged to TA-Endpoints threats and the PC-Endpoints priority compliance map.
• 100% of new endpoint AI deployments approved in the last 90 days have a REM on file.
• ≥90% of active endpoint AI deployments in the SM inventory carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Accepted-gap backlog tracked with every gap carrying a named owner and re-review date; median age inside ≤90 days.
• Cross-Vendors-domain REM cross-reference operating for Critical-tier endpoint AI sourced from external vendors.

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; and validate REM evidence continuously for Critical and High-tier deployments.

Activities.

A) Quantitative and binary requirement pack. For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions. Kill-switch test: binary, emergency-halt mechanism exists, is tested quarterly, and can disable the endpoint AI within four hours of decision with last test date and result on file; zero missed quarterly tests in the last 12 months. Vendor no-train assertion: binary, vendor admin-console setting "Training on your data" confirmed OFF as of the recorded date with screenshot on file; re-verification completed quarterly with zero findings of setting re-enabled in the last 12 months. Art. 50 disclosure (chatbot): binary, disclosure UX component present and persistent on every customer session start, verified in the last ST-Endpoints test run; disclosure text meets Art. 50 specificity; disclosure cannot be suppressed by system prompt (verified via red-team probe with date on file). Extension scope review: binary, each allowlisted AI extension has a completed scope review on file confirming host permissions justified; no extension with <all_urls> permission active on managed endpoints without a named compensating control and expiry date. DLP coverage for AI egress: SLA, DLP rules tuned for AI-specific patterns covering ≥90% of known regulated-data formats; zero undetected regulated-data egress incidents to AI provider domains in the last 90 days. Mobile model integrity attestation: binary, on-device model signing verified at load time; attestation log confirms zero unsigned-model loads in the last 90 days; failed attestation alert routed to ML-Endpoints within five minutes. Edge device firmware attestation: binary, attestation chain verified at boot; backend logs attestation result for every device at every boot; zero unattested boots in the last 90 days. SSO and MFA on AI consoles: binary, SSO enforcement confirmed for all Critical-tier AI consoles via IdP policy log; MFA enforced for all admin access to endpoint AI admin interfaces; zero console logins without MFA in the last 90 days.

B) Per-tier requirement depth. Publish a per-tier pack overlay aligned to the SM L2 tier-treatment matrix. Critical tier: full base pack and all applicable archetype deltas; executive sign-off on the completed REM before Sanctioned status is issued; full REM with no rows left blank; accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; EU AI Act Art. 26 full deployer-duty checklist as a discrete appendix to the REM; Art. 50 disclosure testing required (red-team probe confirming disclosure cannot be suppressed, not just UX screenshot); re-validation of all Critical-tier REM evidence quarterly; cross-Vendors-domain REM cross-reference required. High tier: full base pack and applicable archetype deltas; accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually. Medium tier: base pack and applicable archetype deltas; accepted-gap aging SLA of 120 days; re-validation annually. Low tier: base pack only; fast-track process with abbreviated evidence citations acceptable; re-validation at annual review.

C) REM auto-revalidation and pack updates from IR and IM. Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation wired to observable telemetry: MDM/UEM telemetry (extension allowlist compliance confirmed, unauthorized app install alerts cross-checked against REM), SaaS-admin audit logs (AI feature enablement events confirmed against REM, no unapproved feature enabled since last review), DLP signals (regulated-data egress alerts to AI provider domains cross-checked, zero unresolved alerts in the REM evidence period), vendor admin-console API (no-train setting re-confirmed via API query, not only screenshot), and model integrity attestation log (mobile and edge attestation results pulled from the attestation service, zero unsigned-model loads confirmed). Pack updates from IR and IM: every IM-Endpoints incident that touches a pack requirement triggers a REM row re-validation for the affected deployment and a pack update assessment within 14 days. IR findings that surface a missing requirement category trigger a pack amendment sprint within 30 days. Validation deltas are routed to IM-Endpoints as findings with severity tags and remediation SLAs matching the deployment's tier.

Outcome Metrics (L2).

Success Criteria.

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality (MDM telemetry, SaaS-admin audit log, DLP signals, vendor admin-console API, attestation service) in the last 90 days; validation deltas routed to IM-Endpoints.
• No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor; no High-tier gap beyond 90 days.
• 100% of Critical-tier deployments carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM.
• Per-tier pack overlay published and enforced; SM intake routing verified.
• REM auto-revalidation wired to MDM, SaaS-admin, DLP, and attestation telemetry for Critical and High tiers.

Maturity Level 3

Objective: Express the AI/HAI Endpoints Requirements Pack as a machine-readable artifact, automate REM-evidence validation from MDM/UEM and SaaS-admin signals, and contribute to industry-standard AI endpoint security requirements bodies.

Activities.

A) Machine-readable pack and endpoint-attestation at deploy. Express the Requirements Pack (base plus archetype deltas) in a structured schema (JSON or YAML) where each requirement has an ID, a machine-readable evidence type (MDM-policy-check, admin-console-API, attestation-log-query, DLP-telemetry, or manual-attestation), an acceptance predicate, and a tier applicability field. At deployment or configuration time for Critical and High-tier endpoint AI: automated checks run against the deployment's REM (SSO and MFA confirmed via IdP API, extension allowlist compliance confirmed via MDM policy, no-train setting confirmed via vendor admin-console API, DLP rules active and current, kill-switch mechanism confirmed tested within defined age, model-signing attestation confirmed for mobile and edge deployments); checks that pass write a signed attestation to the REM record; checks that fail block the deployment for Critical-tier and emit a warning with auto-routing to IM-Endpoints for High-tier. Manual-attestation rows (Art. 50 UX review, human-rights-surface documentation) are prompted for re-confirmation at deploy time if the deployment has changed since last manual review.

B) Automated REM-evidence validation from runtime signals. Subscribe the REM validation pipeline to MDM/UEM telemetry (extension allowlist violations, unauthorized app installs, policy-compliance state), SaaS-admin audit logs (AI feature enablement events, admin-console state changes), DLP signals (regulated-data egress alerts to AI provider domains), attestation service logs (mobile and edge device model-integrity and firmware-integrity attestation results), IM-Endpoints incident records (post-incident reviews that touch a pack requirement auto-flag relevant REM rows for re-validation), and SM inventory change events (a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth). Human review is reserved for novel requirement types, Art. 50 UX review, accepted-gap escalations, and Art. 22 affected-persons-rights surface documentation.

C) Standards contribution. Contribute the machine-readable requirement schema and REM schema as open artifacts to the CSA endpoint AI security working group; submit practitioner input on requirement categories and evidence conditions for mobile AI apps and AI-augmented productivity tools to OWASP MASVS AI extensions; submit practitioner commentary grounded in Endpoints REM experience to NIST AI RMF Playbook MEASURE and MANAGE function requirement language; and submit concrete, testable AI endpoint security requirements as candidate clause language to ISO/IEC 27090 or equivalent AI security standards successor work. Target: at least two substantive contributions per year, legally vetted and anonymized.

Outcome Metrics (L3).

Success Criteria.

• Machine-readable pack schema published; ≥80% of Critical-tier REM requirements have endpoint-attestation at deploy time.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions and novel clauses.
• Zero Critical-tier endpoint AI deployments going live with a failing REM check; gate telemetry confirms enforcement.
• Pack and REM schema published under permissive license with tracked external adoption.
• ≥2 substantive industry-standard contributions per year.

Common Pitfalls

Level 1. - The base pack is authored with 40+ requirements at L1, reviewers cannot complete a REM in three business days and begin skipping rows, producing REMs that are structurally complete but evidentially hollow. - Per-archetype deltas are written but never wired into the intake process, every deployment gets the base pack only; chatbot Art. 50 disclosure testing and edge device attestation requirements are missed on every intake for those archetypes. - Gap-accepted rows lack expiry dates and named owners, the backlog grows silently until an audit surfaces a Critical-tier gap that has been "accepted" for 18 months with no action. - No-train assertion is accepted from the DPA contract clause and never verified at the admin-console level, the contractual assertion and the technical state diverge; regulated data trains the vendor's model. - Cross-Vendors-domain REM linkage is documented as a requirement but no process links the two, endpoint reviewers do not know which Vendors REM to reference; the cross-domain traceability gap remains. - Material-change trigger is not defined, new tool access granted to an AI assistant, a SaaS-AI feature gaining new data scope, or an extension scope change ships without triggering a REM re-review.

Level 2. - Quantitative conditions are set too loosely, "kill-switch tested regularly" becomes "annually" on paper but is never confirmed against the actual last test date; the SLA exists but is never verified. - REM re-validation is scheduled quarterly for Critical-tier but samples only what endpoint engineers self-report, MDM telemetry, SaaS-admin audit logs, DLP signals, and attestation logs are never cross-referenced; evidence integrity is unverified. - Art. 50 disclosure validation is a UX screenshot in the REM, the screenshot confirms the disclosure component exists but a red-team probe confirming it cannot be suppressed is never run; the disclosure requirement is nominally met. - Per-tier differentiation is documented in the pack overlay but not enforced at intake, Low-tier deployments receive the same review depth as Critical-tier because the intake routing logic was never built. - Pack updates from IR and IM findings are identified in post-incident reviews but never propagate to the pack, the same missing requirement is discovered in three successive incidents before it is added to the pack.

Level 3. - The machine-readable pack schema is published but the org stops maintaining the public version, the external artifact becomes stale while the internal version evolves; external adopters build on outdated requirements. - Endpoint-attestation covers deploy-time config checks but not post-deploy drift, an extension that passes the scope review at deploy time gains new permissions via an update with no detection, and the attestation log shows "passed." - Standards contributions are submitted to working groups with no active AI endpoint security track, they appear in the contribution log but have no path to adoption and no measurable industry impact. - Automated REM validation reports pass/fail counts to the program dashboard but never feeds failures back to the pack, repeatedly failing checks stay in the pack, generating noise and eroding trust in the gate.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned AI/HAI Endpoints Requirements Pack containing a base set of 20 or fewer requirements plus seven per-archetype deltas, with every requirement tagged to at least one TA-Endpoints archetype threat and one PC-Endpoints priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per deployment at intake? Evidence: Pack document with ID-tagged requirements, quarterly refresh record, and named pack owner. 2. Do 100% of new endpoint AI deployments approved in the last 90 days have a completed REM on file, with every applicable requirement marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, each Met row citing specific verifiable evidence (MDM policy screenshot, admin-console state, extension scope review, attestation log), each Gap-accepted row naming a compensating control, owner, and re-review date, and material-change triggers defined? Evidence: SM intake tickets with attached REM artifacts; gap register with owner and expiry fields populated. 3. Is the pack on a quarterly refresh cadence with a named owner, are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements, and is cross-Vendors-domain REM linkage operating for Critical-tier endpoint AI sourced from external vendors? Evidence: Quarterly refresh records; cross-references from DR, IR, and ST artifacts back to REM row IDs; cross-domain traceability log.

Level 2. 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (kill-switch test age, no-train re-verification cadence, DLP coverage percentage, attestation failure alert time) and binary state (SSO and MFA confirmed, Art. 50 disclosure red-team tested, extension scope review complete, model signing verified) specified, and has all qualitative "appropriate" and "reasonable" language been removed? Evidence: Pack document with no instances of qualitative acceptance language. 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (MDM telemetry, SaaS-admin audit log, DLP signals, vendor admin-console API, attestation service logs) in the last 90 days, with validation deltas routed to IM-Endpoints and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor? Evidence: Validation log with timestamps; gap register with escalation records. 3. Does 100% of Critical-tier deployments carry a full EU AI Act Art. 26 deployer-duty checklist in their REM with verifiable evidence, and is the per-tier pack overlay enforced at SM intake, with Critical-tier deployments receiving full depth (including Art. 50 red-team probe and executive sign-off) and Low-tier receiving base pack only? Evidence: Critical-tier REM appendices; SM intake routing log showing tier-differentiated processing.

Level 3. 1. Is the AI/HAI Endpoints Requirements Pack expressed in a machine-readable schema and enforced via endpoint-attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier deployments going live with a failing REM check, and the schema published under a permissive license with tracked external adoption? Evidence: Attestation log; zero-failure production deploy record; external adoption tracking. 2. Are ≥70% of REM evidence rows auto-validated via MDM/UEM, SaaS-admin, DLP telemetry, and attestation service ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations? Evidence: Validation telemetry showing auto-vs-manual split; false-positive and false-negative rate tracking. 3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, endpoint AI requirement clauses) to recognized standards bodies (CSA endpoint AI / OWASP MASVS / NIST AI RMF Playbook / ISO AI security standards work), with contributions publicly documented and traceable to adoption? Evidence: Contribution log with public links to accepted or in-progress submissions.

19. Secure Architecture (SA)

Practice Overview

Objective: Publish the reference architectures for safely deploying each AI/HAI endpoint archetype the organization uses, so IT, endpoint engineering, and product teams have a vetted green path that already implements SR-Endpoints requirements and contains the threats identified by TA-Endpoints.

Description: SA-Endpoints ships a catalog of reference patterns, one per endpoint AI archetype, showing how to enforce identity, gate data egress, scope tool access, validate inputs and outputs, log endpoint AI activity, and protect model integrity for AI/HAI interfaces deployed on endpoints and customer-facing surfaces. Each pattern covers scope, data boundary, identity and auth, deployment topology, logging, controls mapped to SR-Endpoints requirements, and threats mitigated, tagged to HAI TTPs (EA/AGH/TM/RA) and MITRE ATLAS mitigation IDs. The catalog is accompanied by an anti-pattern list derived from real incidents, industry-observed and first-party. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are extended to multi-region, sector-specific, and tier-conditional variants expressed in MDM configuration profiles and SaaS-admin baselines so teams apply rather than handcraft. At L3, patterns are published as open artifacts contributing to CSA endpoint AI security, OWASP MASVS, OpenSSF AI, and the MITRE ATLAS mitigation library.

Context: Without reference patterns, every team deploying an AI assistant, enabling a SaaS-AI feature, launching a customer chatbot, deploying a mobile AI app, or installing an edge AI device makes the same architectural missteps: AI assistant on unmanaged endpoint with no DLP; browser extension with <all_urls> permission and no scope review; chatbot without Art. 50 disclosure; SaaS-AI feature enabled tenant-wide without intake; mobile AI app with access to all device sensors; edge AI device without firmware signing. The downstream cost is design reviews that repeat the same finding set and incidents that replay avoidable anti-patterns. SA-Endpoints makes the secure path the default path, not by blocking deployment of endpoint AI, but by publishing a pre-vetted architecture for each archetype so teams reach for the pattern first.

Maturity Level 1

Objective: Publish reference architectures per endpoint AI archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Endpoints requirements and TA-Endpoints threats.

Activities.

A) Publish reference architectures per endpoint AI archetype. Publish one pattern per archetype the org actually deploys. Each pattern is concise (target three pages), includes a labeled deployment diagram, and covers a consistent skeleton: scope, data boundary, identity and auth, deployment topology, logging, controls mapped to SR requirements, and threats mitigated with HAI TTP tags and ATLAS mitigation IDs. All seven archetype reference patterns ship at L1. The AI assistant/copilot on managed endpoint pattern requires managed-endpoint enforcement (MDM policy gating assistant use to enrolled devices), SSO and MFA to the AI provider, DLP-tuned egress to AI provider domains, vendor no-train flag enforced and re-verified, tool allowlist for assistants with local tools with per-tool scope minimization, per-session memory bounds documented, and audit log of assistant actions retained and exportable; threats mitigated include confidential-data egress to vendor (DLP plus no-train enforcement), prompt injection via opened files (tool allowlist plus scope minimization), AGH via tool-using assistant (per-session memory bounds plus HITL where applicable), and TM via assistant invoking endpoint tools (tool-call logging plus allowlist). The browser extension pattern enforces an MDM-pinned extension allowlist, per-extension scope review prohibiting <all_urls> without exception, DLP integration for extension traffic where technically feasible, SSO enforcement for extension backend, and extension version pinning. The chatbot pattern requires prompt-injection defense at the input edge, an output filter tested against jailbreak and exfiltration probes, persistent Art. 50 disclosure verified non-suppressible by red-team probe, a documented escalation-to-human path, rate-limit and abuse-detection, per-session memory bounds, and full prompt/completion logging with PII redacted per GDPR Art. 5. The multi-modal pattern requires modality-specific input validation (image content moderation, voice biometric anti-spoof, deepfake detection where required by tier), output safety filters across all modalities, a cross-modal consistency check for high-stakes decisions, and biometric data handling under GDPR Art. 9. The AI-augmented productivity (SaaS-AI) pattern requires SaaS-admin governance preventing tenant-wide AI feature enablement without intake, per-feature data-scope review, conditional enablement for Critical roles and sensitive scopes, admin audit retention, and vendor no-train verification at the admin-console level. The mobile AI pattern requires signed app and signed local model with attestation at load, permission minimization with over-broad permissions blocked, attestation failures routed to ML-Endpoints within five minutes, secure-enclave scoping for sensitive operations, and opt-in for sensor access. The edge AI pattern requires signed firmware and signed model with attestation at boot verified by backend, physical-tamper detection where feasible, uplink traffic signed and encrypted, and remote-disable tested at least annually. Each pattern documents threats mitigated with HAI TTP tags and MITRE ATLAS mitigation IDs aligned to the primary SA-Endpoints tactics: TA0007 Privilege Escalation (tool-scope minimization, extension scope review, managed-endpoint enforcement, permission minimization), TA0008 Defense Evasion (chatbot output filter, modality-specific input validation, model signing verification), TA0011 Exfiltration mitigated for AML.T0024 (DLP at endpoint, no-train enforcement, uplink signing and encryption), and TA0005 Persistence (firmware and model signing, per-session memory bounds).

B) Publish the anti-pattern catalog. Name, describe, and prohibit endpoint AI architectural patterns that reliably produce incidents. Each entry includes description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it. The L1 set covers AI assistant on unmanaged endpoint (replaced by managed-endpoint requirement and SSO enforcement); browser extension with <all_urls> permission and AI backend (replaced by extension allowlist plus per-extension scope review); chatbot without Art. 50 disclosure (replaced by chatbot pattern Art. 50 disclosure on every customer interaction); multi-modal without input validation (replaced by modality-specific input validation); SaaS-AI feature enabled tenant-wide without intake (replaced by SaaS-admin governance requiring intake before enablement); mobile AI with broad permissions (replaced by permission minimization and opt-in for sensor access); edge AI without firmware/model signing (replaced by signed firmware and signed model with attestation at boot); no-train assertion trusted from contract text alone (replaced by admin-console-level verification with recurrent re-verification); endpoint AI with no kill-switch (replaced by base pack kill-switch requirement and per-archetype disable path); and chatbot with no escalation-to-human path (replaced by chatbot pattern escalation-to-human path documented and operational).

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path. SM inventory records link to the applicable reference pattern(s) at intake. Teams choosing an archetype see the reference pattern and declare "using pattern" or "deviating from pattern." Deviations require a lightweight design review (DR-Endpoints L1) with a named architect reviewer and a documented rationale stored with the deployment's inventory record. Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction (three or more deviations in the same direction for the same archetype) automatically queue a pattern-update review with SA ownership rather than continued exception approval. New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1).

Success Criteria.

• Seven reference patterns published, one per archetype, each with a labeled deployment diagram, scope declaration, data-boundary definition, identity and auth model, deployment topology, logging spec, and row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs.
• Anti-pattern catalog published with at least 10 entries, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training; each entry tied to the real incident that generated it.
• Deviation-review path operational with a named architect-reviewer population and ≤5 business day SLA; repeat-deviation signal wired to queue pattern updates.
• ≥85% of active endpoint AI deployments in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of chatbot and conversational UI deployments with a confirmed Art. 50 disclosure implementation on file, verified by ST-Endpoints test, not only UX screenshot.

Maturity Level 2

Objective: Extend reference patterns to multi-region, sector-specific, and tier-conditional variants calibrated to SM L2's tier-treatment matrix; encode patterns as MDM configuration profiles and SaaS-admin baselines with conformance checks; update the anti-pattern catalog from IM-Endpoints incidents.

Activities.

A) Tier-conditional pattern extensions. Publish extended pattern variants calibrated to SM L2's tier-treatment matrix. The Critical-tier overlay (applies to any archetype at Critical tier) adds per-tenant isolation enforced (customer data from different tenants does not co-mingle in the endpoint AI's context or log storage); sector-specific regulatory overlay (FS: FINRA/SEC model risk controls for AI-assisted financial advice; Healthcare: FDA AI-enabled device guidance and HIPAA PHI handling for AI health tools; HR: GDPR Art. 9 biometric data controls for multi-modal HR interfaces); kill-switch MDM configuration baseline (documented MDM policy payload that disables the endpoint AI, tested quarterly, activation SLA ≤4 hours); EU AI Act Art. 26 full deployer-duty controls explicitly mapped in the pattern; and Art. 50 disclosure testing requirement (red-team probe confirming disclosure cannot be suppressed by any known jailbreak technique). The High-tier overlay includes monitoring and logging MDM/SaaS-admin modules pre-wired with AI-tool-use event logging, DLP alert routing, extension install telemetry, and admin-audit log forwarding to SIEM, with standard ML-Endpoints L2 detections pre-configured. The multi-region/cross-border pattern covers data-residency enforcement for global endpoint AI deployments (region pinning at the SaaS-admin console or MDM policy), cross-region data transfer controls aligned to GDPR Arts. 44–49, and transfer mechanism selection as a required decision gate. The managed-endpoint enforcement pattern requires MDM enrollment verification before any Critical-tier endpoint AI is accessible via a conditional access policy (enrollment confirmed by IdP/MDM before access is granted) with a BYOD risk-accept process and documented compensating controls.

B) Patterns as MDM configuration profiles and SaaS-admin baselines. All Critical and High-tier pattern variants encoded as deployable MDM configuration profiles (Apple MDM, Intune, Workspace ONE, or equivalent) and SaaS-admin configuration baselines (M365 admin center policies, Google Workspace admin settings, Salesforce admin configuration, Slack admin settings) so teams apply rather than handcraft; deviations surface at policy-compliance reporting time. Each MDM profile or admin baseline ships with a conformance check: automated or admin-report-based checks that the deployed configuration matches the pattern's controls (no-train setting confirmed, extension allowlist applied, DLP rules active, audit logging forwarded to SIEM, kill-switch mechanism configured). Configuration profiles are version-pinned; profile updates trigger a drift-detection pass against all enrolled deployments. A profile change log is maintained; teams consuming a profile are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh. Every IM-Endpoints incident is classified to an anti-pattern (existing or new); classification is recorded in the IM finding. The catalog is refreshed monthly from IM-Endpoints findings; new anti-patterns are surfaced to teams at intake time rather than stored only in a reference document. Quarterly review: if three or more deployments have deviated from a pattern in the same direction, the pattern is queued for update rather than continued exception approval. Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2).

Success Criteria.

• Four tier-conditional extended patterns published (Critical overlay, High overlay, multi-region, managed-endpoint enforcement), each encoded as a deployable MDM configuration profile or SaaS-admin baseline with conformance checks.
• ≥80% of Critical and High-tier endpoint AI deployments running on encoded patterns with drift-detection.
• Anti-pattern catalog updated from ≥3 real IM-Endpoints incidents in the last 12 months; new entries surfaced at intake time.
• Conformance check coverage at 100% of encoded deployments.
• 100% of Critical-tier deployments with EU AI Act Art. 26 and Art. 50 controls explicitly mapped in the pattern documentation.

Maturity Level 3

Objective: Publish reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage standards bodies and regulators on architecture norms for AI/HAI endpoint deployment.

Activities.

A) Publish reference patterns as open artifacts. Publish patterns under Apache 2.0 or equivalent open license via OWASP MASVS, CSA endpoint AI security initiative, OpenSSF AI, or equivalent body; sector-specific variants through relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups). Maintain the public repository as the upstream source; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks. Track pattern adoption telemetry: GitHub forks, citations in published work, documented adopters. New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS mitigation library. For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx). Priority contributions align to SA-Endpoints primary ATLAS tactics: TA0007 Privilege Escalation (extension scope minimization, tool allowlist, managed-endpoint enforcement, permission minimization), TA0008 Defense Evasion (chatbot output filter, modality-specific input validation, model signing verification), TA0011 Exfiltration mitigating AML.T0024 (DLP at endpoint, no-train enforcement, uplink signing and encryption), and TA0005 Persistence (firmware and model signing, per-session memory bounds). Target at least two AML.M00xx entries proposed or validated per year, traceable to specific SA-Endpoints pattern controls. Participate in the ATLAS practitioner community to align SA-Endpoints control vocabulary with ATLAS technique taxonomy.

C) Engage regulators and standards bodies on endpoint AI architecture norms. Participate actively in EU AI Act Art. 50 implementing guidance consultations where technical standards for AI-interaction disclosure are under discussion; submit SA-Endpoints chatbot pattern's disclosure controls as evidence of "state of the art." Contribute to ISO/IEC 42001 AIMS community guidance on endpoint AI deployment documentation. Engage NIST AI RMF Playbook successor editions with SA-Endpoints pattern mappings to GOVERN, MAP, MEASURE, and MANAGE. Contribute to OWASP MASVS AI extensions with the mobile AI app pattern as input to MASVS mobile AI security controls and to the OWASP Browser-Extension Security Top 10 with the browser extension pattern. Engage sector regulators (FINRA/SEC on AI-assisted financial advice endpoint controls, HHS/FDA on AI-enabled device firmware signing, NYDFS Part 500 on AI endpoint security) with sector-relevant pattern variants and seek inclusion in sector architecture guidance.

Outcome Metrics (L3).

Success Criteria.

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

Common Pitfalls

Level 1. - Patterns are written but not linked from the SM inventory record or the intake gate, teams skip them because they are hard to find, not because they disagree with them. - The chatbot pattern omits the output filter and the Art. 50 red-team probe, the two controls most directly required by EU AI Act Art. 50 and most commonly missing from chatbot deployments. - Anti-patterns remain theoretical; they are not tied to real incidents or to the specific pattern element that replaces them, so deployment teams do not recognize the hazard when they encounter it. - Deviations are approved individually but the repeat-deviation signal is never wired, patterns never update because no one aggregates the pattern-update trigger. - The AI assistant pattern describes SSO and MFA and managed-endpoint enforcement in the document but the MDM policy enforcing managed-endpoint access has not been configured, AI assistants are used on personal devices from day one. - The edge AI pattern covers firmware signing and attestation in the diagram but the attestation service is not deployed, devices boot with unsigned firmware and the pattern is aspirational.

Level 2. - MDM configuration profiles are forked once and then hand-edited at each deployment, drift is immediate and the profile substrate provides no baseline enforcement; conformance checks are skipped because they block the fastest path to production. - Tier-conditional patterns exist in documents but the MDM profiles do not enforce the tier-specific controls, the Critical overlay exists on paper; deployed Critical-tier deployments lack per-tenant isolation or kill-switch MDM configuration. - Anti-pattern catalog grows from incidents but is only accessible as a reference document; teams encounter the anti-pattern again before they encounter the catalog entry. - Multi-region pattern covers data-residency in the diagram but does not include the GDPR international-transfer mechanism selection step, teams deploy cross-region endpoint AI data flows without a legal basis. - Managed-endpoint enforcement pattern exists but the conditional access policy in the IdP is never configured, AI assistants continue to be accessed from personal devices because the enforcement was not implemented.

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

Practice Maturity Questions

Level 1. 1. Are seven reference patterns published, one per archetype (AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device), each with a labeled deployment diagram, data-boundary definition, identity and auth model, deployment topology, logging spec, and explicit row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record? Evidence: Pattern catalog with seven versioned documents; SM inventory record containing direct links. 2. Are 100% of chatbot and conversational UI deployments verified via ST-Endpoints test (not only UX screenshot) to have a persistent Art. 50 disclosure that cannot be suppressed, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training, with each entry tied to the real incident that generated it? Evidence: ST-Endpoints test results for chatbot disclosure non-suppression; anti-pattern catalog linked from AUP, intake gate, and EG training curriculum. 3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active endpoint AI deployments in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations? Evidence: Pattern metadata showing on-pattern or deviation-with-review status; deviation aggregation report from the last quarter.

Level 2. 1. Are the four tier-conditional extended patterns (Critical overlay, High overlay, multi-region, managed-endpoint enforcement) published as deployable MDM configuration profiles or SaaS-admin configuration baselines with conformance checks, and are ≥80% of Critical and High-tier endpoint AI deployments running on encoded patterns as confirmed by MDM compliance reporting and the SM inventory? Evidence: MDM profile and SaaS-admin baseline repository; conformance check run history; SM inventory showing tier-to-pattern alignment. 2. Has the anti-pattern catalog been updated from ≥3 real IM-Endpoints incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and does conformance checking cover 100% of encoded deployments with findings tracked to resolution? Evidence: Anti-pattern change log with IM incident references; intake gate showing current anti-pattern catalog version; conformance check coverage report. 3. Are 100% of Critical-tier deployments carrying explicit EU AI Act Art. 26 and Art. 50 control mappings in the pattern documentation, and is the tier-treatment matrix from SM L2 reflected in the pattern variants, Critical deployments getting the Critical overlay (including Art. 50 red-team probe and kill-switch MDM configuration), High deployments getting the High overlay, Medium/Low following the base pattern? Evidence: Critical-tier pattern documents with Art. 26/Art. 50 mapping sections; SM intake routing log showing tier-differentiated pattern assignment.

Level 3. 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? Evidence: External repository with license file; citation or fork count; internal-vs-external pattern diff audit with no unexplained deviations. 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Endpoints pattern controls aligned to ATLAS primary tactics TA0007 Privilege Escalation, TA0008 Defense Evasion, TA0011 Exfiltration (mitigating AML.T0024), and TA0005 Persistence, and is there an active ATLAS practitioner engagement cadence? Evidence: ATLAS contribution log with PR or submission references; meeting records from ATLAS practitioner community. 3. Is there at least one documented reference to SA-Endpoints patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation? Evidence: Regulatory engagement log with document references and citation extracts; engagement calendar with active items.

20. Design Review (DR)

Practice Overview

Objective: Operate the design checkpoint between intake approval and deployment for every AI/HAI-enabled endpoint or user-facing AI interface, confirming the proposed design follows the applicable SA-Endpoints reference pattern, covers the SR-Endpoints requirements pack, and documents residual risks before rollout begins.

Description: DR-Endpoints is the single moment where endpoint architecture (SA-Endpoints), requirements (SR-Endpoints), and threats (TA-Endpoints) meet a specific planned deployment of an AI/HAI-enabled endpoint. The review runs before the deployment team begins rollout, catching deviations when they cost hours to correct, not sprints. A two-lane model routes Low / Medium-tier deployments to an async fast-lane (target ≤2 business days) and High / Critical-tier, customer-facing, regulated-data, or sector-scoped cases to a full-lane architect review (target ≤5 business days). Every review produces a written decision (approve / approve-with-conditions / send-back) stored against the SM-Endpoints inventory record. Loop-back signals ensure the review process improves SA-Endpoints patterns and SR-Endpoints packs over time rather than accumulating silent technical debt.

Context: Without an endpoint design checkpoint, AI/HAI user-facing interfaces deploy without a verified data boundary, without a confirmed DLP scope, without output-filter placement, and without a kill-switch path. An AI assistant rolls out to managed endpoints before SSO and DLP are confirmed in scope. A browser extension is approved without a scope review. A customer-facing chatbot goes live without EU AI Act Art. 50 disclosure in the UX. A SaaS-AI feature is enabled tenant-wide while the data-scope question is still open. DR-Endpoints enforces the handoff between "design approved" and "deployment begins," making deviations visible and deliberate. EU AI Act Art. 50 requires disclosure for AI interactions at the UX surface; the DR decision record is the documented pre-deployment decision that confirms disclosure is present.

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every AI/HAI-enabled endpoint rollout before deployment, producing a written decision traceable to the SA-Endpoints pattern, the SR-Endpoints requirements pack, and the TA-Endpoints threat snapshot.

Activities.

A) Publish the per-archetype AI/HAI Endpoints Design Checklist. One checklist per SM-Endpoints archetype, derived from the applicable SA-Endpoints reference pattern and keyed to the SR-Endpoints base pack and archetype delta. The seven checklists share a common spine, pattern adherence (using the SA reference pattern or documented deviation with rationale), identity (managed-endpoint requirement confirmed for Critical-tier AI; SSO-backed human access to all admin and operational interfaces; service-principal model for automated access; secrets-vault-backed API keys to AI vendors with no hardcoded credentials in configuration), DLP at the endpoint boundary (DLP inspection scope defined for the archetype; data classes flowing to the AI component declared; DLP policy wired and active at the endpoint boundary), vendor no-train probing (vendor no-train commitment confirmed via admin API or admin-console setting, not from contract language alone), Art. 50 disclosure (for customer-facing or user-interactive AI interfaces, EU AI Act Art. 50 disclosure present in the UX design with an evidence pointer linked from the DR record), logging (interaction, admin-audit, and identity events captured per the SR base pack with retention meeting the longest applicable regulation and an export mechanism defined), kill-switch / disable path (emergency-halt mechanism in the design with a test plan and a named owner for the disable action), and affected-persons rights surface (DSAR or rights-exercise surface identified and mapped in the design), plus archetype-specific additions. The AI assistant on managed endpoint checklist adds: managed-endpoint requirement (Critical-tier assistants require MDM-enrolled device); SSO and DLP scope confirmed; tool-allowlist declared (assistant cannot invoke tools not explicitly listed); audit-log completeness confirmed (all invocations captured with user identity and timestamp). The browser-based AI tool checklist adds extension allowlist verification, extension scope review (declared permission set matches the minimum required), browser-DLP integration, and backend SSO. The chatbot / conversational UI checklist adds prompt-injection defense in the design (system prompt isolated from user input), output filter present before response reaches the user, Art. 50 UX disclosure on every interaction, and an escalation path to a human within the declared SLA. The multi-modal AI interface checklist adds modality-specific input validation, output safety filter per modality, cross-modal consistency test, and Art. 50 disclosure for each interaction mode. The SaaS-AI productivity checklist adds intake review before tenant-wide enablement, per-feature data scope declaration, conditional enablement design (role-scoped or group-scoped, not all-tenants by default), and admin-audit events for feature enablement. The mobile AI app checklist adds signed-app and signed-local-model verification, permission minimization, and on-device integrity attestation. The edge AI device checklist adds signed firmware and model, secure-boot and attestation, physical-tamper detection, and a remote-disable path. For the chatbot archetype, reviewers verify HAI TTPs explicitly: AGH (system-prompt isolation and indirect-injection defenses), TM (output-filter and tool-call scoping where the chatbot invokes downstream tools), EA (no broader workspace access than the declared use case), and RA (multi-turn session bounds and termination conditions). For the edge AI device archetype, reviewers verify the supply-chain integrity chain end to end (firmware signature, model signature, attestation report path).

B) Triage and route reviews by risk tier and deployment status. The two-lane model is driven by the SM-Endpoints tier assignment and the deviation flag. Fast-lane (Low / Medium tier, on-pattern): async checklist review by the designated reviewer, target SLA ≤2 business days; output is one structured decision record (approve / approve-with-conditions with explicit list / send-back with reasons) stored against the SM-Endpoints inventory record. Full-lane (High / Critical tier, or customer-facing, or regulated data, or sector-scoped, or any pattern deviation): 45–60 minute architect review with the deployment team walking the SA-Endpoints reference pattern section-by-section, target SLA ≤5 business days; output is a written decision record with the residual-risk list reviewed by a named architect. Before SM L2 tiers are formalized, customer-facing chatbots and AI interfaces, and any endpoint deployment processing regulated data, default to full-lane; all others default to fast-lane with override to full-lane available on reviewer judgment. Every decision record, both lanes, carries: decision; checklist completed with evidence pointers; deviations listed with rationale; residual risks listed with named owner and expiry; reviewer name and date; links to the SM-Endpoints inventory record, the TA-Endpoints threat snapshot, and the SR-Endpoints REM.

C) Close the loop with SA-Endpoints, SR-Endpoints, and IM-Endpoints. Design review is a learning surface for the program. Three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Endpoints ownership, recurring deviations signal the pattern is miscalibrated, not that deployment teams are wrong. An SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review. Every IM-Endpoints incident re-examines the DR decision record that approved the affected endpoint: was the issue visible at design time, and which checklist item would have caught it? The answer updates the checklist and feeds the next archetype review cycle.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype design checklists published, versioned, and traceable to the applicable SA-Endpoints reference pattern, SR-Endpoints requirements pack, and TA-Endpoints threat snapshot, with the chatbot checklist covering prompt-injection defense and Art. 50 UX, the SaaS-AI checklist covering intake-before-enablement, and the edge device checklist covering signed firmware and remote-disable.
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype trained on EG-Endpoints L1.
• ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record before deployment begins.
• SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Endpoints incident re-examines the DR record that approved the affected endpoint.

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Endpoints per-artifact threat models, run a SaaS-admin handoff review before tenant-wide AI feature enablement, and detect design drift for High and Critical endpoints on a published cadence.

Activities.

A) Scenario-based reviews for Critical and High-tier endpoints. For every Critical-tier endpoint, the full-lane checklist walkthrough is replaced by a scenario walkthrough. The reviewer sources 3–5 specific threat scenarios from the TA-Endpoints per-artifact deep threat model and the TA-Endpoints archetype library. Scenarios must be specific to this endpoint's declared tool set, data classes, user population, and output-integrity-critical paths, not generic archetype scenarios. Each scenario is walked as: "If an adversary does X at this endpoint, does the proposed design have a control that prevents or detects it? Where? What is the residual risk?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry. Scenario sources include the TA-Endpoints per-artifact deep threat model, anonymized IM-Endpoints incidents from the same archetype, MITRE ATLAS technique candidates relevant to the endpoint's primary control surface (TA0001 Reconnaissance and TA0003 Initial Access for chatbot and conversational UI surfaces; TA0004 ML Model Access for AI assistant tool surfaces; TA0013 Exfiltration for SaaS-AI data-scope surfaces), and OWASP MASVS (mobile), OWASP Browser-Extension Top 10 (browser tool), and OWASP LLM / Agentic Top 10 (chatbot / AI assistant) entries relevant to the archetype. For High-tier endpoints, the standard full-lane review is augmented with at least one scenario from the TA archetype library.

B) SaaS-admin handoff review for tenant-wide AI feature enablement. Before any SaaS-AI feature (Copilot, Notion AI, Slack AI, Workspace AI, or equivalent) is enabled tenant-wide, a dedicated DR handoff review confirms: the enable workflow is documented (who approves, who executes, what constitutes an authorized enablement event); the data scope for the feature is declared (which workspace content the AI feature can access and which is excluded); conditional enablement is configured where possible (role-scoped or group-scoped, not all-tenants by default); the admin-audit log is confirmed to capture the enablement event; and a drift-detection hook is in place to flag unauthorized or silent re-enablement. The DR decision record for SaaS-AI features explicitly identifies the admin-console states that constitute the "approved posture," so that IR-Endpoints L2 can compare live admin-console state against the record. Where the SaaS vendor does not expose admin-API controls for the feature, the DR record notes this gap as a residual risk with a named owner and a compensating control (contractual commitment, manual quarterly audit).

C) Design-drift detection. The live endpoint posture is compared against its approved DR design at a published cadence. Critical-tier: quarterly drift check, examining MDM policy state (DLP rules active, extension allowlist enforced, AI assistant scope matches design), browser admin policy state (extension allowlist enforced, per-extension scope honored), SaaS admin state (which AI features enabled per tenant / role matches design), chatbot Art. 50 disclosure still rendered (sample-check live UX), mobile app version and local-model signature current, and edge device firmware and model signature current. High-tier: annual drift check using the same sources. Material drift, DLP scope widened, new AI feature enabled tenant-wide without DR, Art. 50 disclosure removed, tool-allowlist changed, managed-endpoint requirement dropped, automatically re-opens the DR record and routes back through the appropriate lane. Each drift check produces a written artifact: the diff between approved design and live configuration, each delta classified as material or non-material, with material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• SaaS-AI handoff review process operational; 100% of tenant-wide AI feature enablements in the last 90 days have a prior DR record.
• Design-drift detection operating quarterly for Critical and annually for High; 100% of material drifts re-routed to DR.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

Objective: Operate continuous design attestation via MDM, browser-policy, and SaaS-admin compliance scans, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to CSA endpoint working groups, OWASP MASVS, and OASIS.

Activities.

A) Continuous design attestation via MDM, browser-policy, and SaaS-admin compliance scans. Critical-tier endpoints produce a daily attestation signal covering: MDM policy compliance (DLP rules active and matching the approved design, extension allowlist enforced, managed-endpoint AI assistant scope confirmed); browser admin policy state (extension allowlist enforced, per-extension scope honored, sourced from Chrome / Edge / Safari admin APIs); SaaS admin compliance (AI features enabled per tenant / role match the DR-approved posture, sourced from M365 / Slack / Workspace / Notion admin APIs); chatbot Art. 50 disclosure rendered (automated probe confirms disclosure present in live UX); mobile app version and local-model signature current (sourced from mobile MDM); and edge device firmware and model signature current (sourced from device attestation reports). Deviations from the approved design automatically open a DR-exception ticket in IM-Endpoints, triaged within 3 business days. Attestation artifacts are machine-readable and regulator-consumable, EU AI Act Art. 9 risk-management evidence and deployer-duty records per Art. 26 are produced by the attestation pipeline without manual assembly. Human reviewers handle novel endpoint configurations that do not fit existing attestation rules, accepted exceptions with documented rationale, and escalations from the IM-Endpoints backlog.

B) Contribute review rubrics and scenario templates to industry. Publish under Apache 2.0 or equivalent through CSA endpoint working groups, OWASP MASVS extensions (mobile and browser-based AI tools), and OASIS AI assurance standards: per-archetype AI/HAI endpoint design review rubrics (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS tactics and OWASP MASVS controls); scenario template libraries (scenario format, per-archetype examples for each of the seven endpoint archetypes, debrief rubric for calibration exercises); and a pattern-evolution framework (how external signals, ATLAS updates, sector ISAC advisories, IM incidents, feed DR checklist and scenario updates on a quarterly cadence). Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked. Adoption is tracked by citations, forks, and direct acknowledgment from peer organizations or standards bodies.

C) Pattern evolution driven by external and internal signals. A quarterly pattern-evolution review combines external signals (MITRE ATLAS technique additions relevant to endpoint AI archetypes; OWASP MASVS revisions; sector ISAC AI-specific endpoint advisories; OWASP Browser-Extension Top 10 updates; OWASP LLM / Agentic Top 10 revisions) with internal signals (IM-Endpoints incident patterns by archetype, ML-Endpoints telemetry anomalies, ST-Endpoints red-team findings) to produce structured checklist and scenario library updates. Updates are change-logged with signal provenance; downstream DR records for in-flight reviews are notified of pattern changes affecting their archetype. Where a new ATLAS technique or IM incident reveals a checklist gap, the gap is propagated to SA-Endpoints and SR-Endpoints to maintain the full traceability chain from threat to requirement to design review.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier endpoints across MDM, browser-policy, and SaaS-admin compliance sources; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year (per-archetype rubrics, scenario templates, or pattern-evolution frameworks) with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the routine review volume.
• Quarterly pattern-evolution cadence traceable to external (MITRE ATLAS, OWASP MASVS, sector ISACs) and internal (IM-Endpoints, ML-Endpoints, ST-Endpoints) signals with a versioned change log.

Common Pitfalls

Level 1. - Design review runs after the deployment team has already rolled out the AI feature, the checkpoint loses leverage because rework cost is already sunk; the review becomes a retrospective, not a gate. - Checklists are identical across archetypes, the chatbot checklist does not include prompt-injection defense or Art. 50 UX because it was copy-pasted from the AI assistant checklist. - Fast-lane becomes the default for everything, customer-facing chatbots and regulated-data endpoints slip through with a 15-minute async check rather than the full-lane architect session they require. - Approve-with-conditions is issued but conditions have no named owner and no expiry, conditions sit unresolved at go-live with no enforcement path. - Residual-risk list is blank because the reviewer does not want to document risk, the design record understates real exposure.

Level 2. - "Scenario-based" review is the same checklist read aloud in a meeting, same items, different format; the scenario-to-design-control mapping is never actually performed. - SaaS-AI handoff review exists on paper but SaaS platform admins enable AI features directly from vendor dashboards without routing through DR, the intake step is bypassed. - Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live endpoint posture has diverged. - Scenario library is not refreshed quarterly, scenarios pulled from a 12-month-old TA snapshot do not reflect the current TA-Endpoints per-artifact model or recent IM-Endpoints incidents.

Level 3. - Attestation signals show green across all Critical endpoints but underlying checks cover only MDM enrollment status, DLP scope, extension-allowlist enforcement, and Art. 50 disclosure presence are not checked; attestation is cosmetic. - Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed endpoints 18 months ago; peer adopters find inconsistencies when comparing the rubric to actual DR records. - Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every minor MDM policy update opens a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - Industry contributions are conference talks describing the program, no technical artifacts (rubrics, scenario templates, pattern-evolution frameworks) land in OWASP MASVS / CSA / OASIS with documented adoption.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned per-archetype AI/HAI Endpoints Design Checklist, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with the chatbot checklist covering prompt-injection defense, output filter, Art. 50 UX disclosure, and escalation path, the SaaS-AI checklist covering intake-before-enablement and data-scope declaration, and the edge device checklist covering signed firmware, boot attestation, physical-tamper detection, and remote-disable? Evidence: Checklist documents with version history; traceability matrix linking each item to an SA pattern control and SR requirement; archetype-specific sections signed off by the named lead reviewer. 2. Do ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before deployment begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Endpoints L1, and a residual-risk list with named owner and expiry in every record? Evidence: SM-Endpoints inventory query showing last-90-days production entries with DR decision record IDs linked; review SLA telemetry report; sample of 5 decision records showing residual-risk section populated. 3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA pattern-update and SR pack-update reviews, and does every IM-Endpoints incident trigger a re-examination of the DR record that approved the affected endpoint? Evidence: SA pattern-update queue entries with triggering deviation counts; SR pack-update tickets linked to waiver patterns; IM incident post-mortems with a DR-record re-examination section completed.

Level 2. 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Endpoints per-artifact deep models and anonymized IM-Endpoints incidents, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? Evidence: Critical-tier DR decision records from the last 90 days, each showing a scenario-to-design-control mapping table and a decision statement tied to scenario outcomes. 2. Is a SaaS-AI handoff review required before every tenant-wide AI feature enablement, confirming the enable workflow, approval chain, per-feature data-scope declaration, conditional-enablement configuration, and drift-detection hook are in place and documented in the DR record? Evidence: SaaS admin audit log entries for AI feature enablement cross-referenced to DR handoff records; sample handoff record showing the data-scope declaration and drift-detection hook entries populated. 3. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using MDM telemetry, browser admin policy state, SaaS admin audit feeds, mobile MDM, and edge device attestation reports, with 100% of material drifts automatically re-routed to DR for a new review? Evidence: Drift-detection run log with cadence dates; material-drift classification report showing re-routed endpoints; DR queue entries with drift-triggered source tag.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily automated attestation signal, checking MDM policy compliance, browser-policy enforcement, SaaS-admin feature state, Art. 50 disclosure presence, and device signature currency, with deviations auto-opening DR-exception tickets triaged within 3 business days? Evidence: Attestation telemetry dashboard showing daily signal per Critical endpoint; DR-exception ticket queue with open/triage timestamps; sample attestation artifact in machine-readable format. 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented adoption and internal practice aligned to the published versions? Evidence: Contribution log with external publication links and adoption indicators; comparison document showing internal checklist aligned to the published version. 3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS updates, OWASP MASVS revisions, sector ISAC advisories) and internal signals (IM-Endpoints incidents, ML-Endpoints telemetry, ST-Endpoints findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes? Evidence: Quarterly pattern-evolution review minutes with signal-source citations; versioned checklist change log; in-flight DR review notification records for the most recent pattern update.

21. Implementation Review (IR)

Practice Overview

Objective: Verify, at deployment and on a recurring cadence, that the actual configuration of AI/HAI-enabled endpoints and user-facing AI interfaces matches the design approved at DR, and that it stays there as the endpoint evolves.

Description: IR-Endpoints is the configuration check for AI/HAI endpoint deployments, the moment a reviewer opens the MDM console, the browser admin policy dashboard, the SaaS admin audit log, and the device attestation report and confirms that what is running matches the DR decision record. At L1 the review runs at deployment, at least annually, and on material change (new AI feature enabled tenant-wide, DLP scope changed, Art. 50 disclosure removed, extension-allowlist updated, model or firmware signature changed). At L2, IR-Endpoints consumes MDM webhook events, browser-policy state feeds, SaaS-admin webhooks, mobile MDM scan deltas, edge device attestation freshness, and vendor admin API probes to detect configuration drift continuously for High and Critical-tier endpoints. Findings are severity-tagged and SLA-bound per the SM-Endpoints L2 tier-treatment matrix; they feed IM-Endpoints for tracking and resolution. Vendor no-train flags, Art. 50 disclosure rendering, and logging flows are probed recurrently, not trusted from contract language or design text alone.

Context: The gap between the approved endpoint design and the deployed configuration is the primary source of silent security exposure in AI/HAI endpoint deployments. A chatbot's Art. 50 disclosure is present in the DR record but removed in a UX refresh. A SaaS-AI feature is scoped to the HR workspace in the DR checklist but enabled org-wide by a platform admin. A managed-endpoint AI assistant is approved for MDM-enrolled devices but also installed on personal BYOD via an undetected sideload. A browser extension is approved with three host permissions but the live build requests fifteen. IR-Endpoints closes these gaps by making the implementation check systematic, evidence-based, and recurring, not a one-time pre-launch checkbox or a scramble when an incident reveals a configuration regression.

Maturity Level 1

Objective: Run per-archetype implementation reviews at deployment, annually, and on material change, verifying deployed endpoint configuration matches the SA-Endpoints pattern, the DR decision, and the SR-Endpoints REM evidence is current.

Activities.

A) Publish the per-archetype implementation review checklist. One checklist per SM-Endpoints archetype, focused on the configuration points where production reality most commonly drifts from the approved design. Each item is a yes/no with a required evidence artifact (MDM policy export, admin-console screenshot, SaaS audit log entry, device attestation report, log sample). The common spine across all archetypes covers: MDM policy applies as designed (DLP rules active and matching the approved scope, AI assistant or app allowlist enforced, policy deployment scope matches the approved endpoint population, confirmed via MDM console export from Jamf / Intune / Kandji, not from design text alone); config matches DR decision (the DR-approved posture for this archetype's configuration points is reflected in the live admin state, with deviations flagged); SR REM evidence is current (a stratified sample of REM rows verified against current observable reality, Art. 50 disclosure confirmed via live UX sample-check, vendor no-train flag verified via admin API not from contract alone, logging confirmed via log-export test, kill-switch path confirmed to function with a test record on file); logging is actually flowing to SIEM (pull a sample of interaction, admin-audit, and identity events and confirm format and retention match the SR REM); and kill-switch / disable path actually works when triggered (execute the test and record the result). The AI assistant on managed endpoint checklist adds MDM-policy-applies verification, SSO enforcement test (unauthenticated session rejected), tool-allowlist enforcement in deployed configuration, and audit-log completeness sampling. The browser-based AI tool checklist adds browser admin policy export verification (extension allowlist enforced), per-extension scope honored (installed-extension manifest compared against DR-approved manifest), DLP integration tested, and backend SSO sign-in flow tested. The chatbot / conversational UI checklist adds Art. 50 disclosure rendered in live UX (sample-check with screenshot evidence), output filter active (known-bad input blocked), prompt-injection defense in the deployed system-prompt structure, and escalation-path functionality tested. The multi-modal AI interface checklist adds modality-specific input validation active for each declared modality, output safety filter applied per modality, and cross-modal consistency confirmed. The SaaS-AI productivity checklist adds SaaS admin state matches design (verified via M365 / Slack / Workspace / Notion admin console export), admin-audit log capturing AI feature enablement events, conditional enablement confirmed, and vendor no-train flag verified via admin API. The mobile AI app checklist adds app-version and local-model signature currency, permission minimization confirmed, and on-device integrity attestation passing. The edge AI device checklist adds firmware and model signature currency, secure-boot attestation passing, physical-tamper detection functional, uplink encryption verified against the DR-approved cipher suite, and remote-disable command tested. ATLAS drift sources checked across endpoint archetypes: TA0003 Initial Access (managed-endpoint requirement and extension-allowlist enforcement not relaxed since DR), TA0008 Defense Evasion (logging and Art. 50 disclosure not disabled), TA0013 Exfiltration (DLP scope not narrowed and SaaS-AI data scope not widened). For the chatbot archetype, HAI TTPs are explicitly verified: AGH (system-prompt and instruction-isolation present in the deployed prompt), TM (output-filter wired in the response path), EA (chatbot does not invoke tools beyond the DR-approved allowlist), and RA (multi-turn session bounds enforced).

B) Perform reviews at the right moments. Three triggers at L1: deployment (before the endpoint AI capability goes live or a new version is rolled out, verify the deployed configuration against the DR-approved design; no production rollout with a blocker finding open); annual (every active AI/HAI-enabled endpoint reviewed at least annually, scheduled from the SM-Endpoints inventory with a last-IR-date field linked to a review-due alert); material-change (any of the following triggers an ad-hoc review before the change goes live, SaaS-AI feature enabled tenant-wide, DLP scope changed, extension-allowlist updated, AI assistant or app version changed beyond the DR-approved range, Art. 50 disclosure UX modified, local model or firmware signature changed, managed-endpoint requirement scope changed, vendor no-train or data-handling setting changed). Reviews are evidence-based, MDM exports, admin-console screenshots, SaaS audit log entries, or device attestation reports stored with the IR record. Target timebox: 20–60 minutes per endpoint depending on archetype complexity.

C) Track findings to closure. Every review produces zero or more findings. Each finding carries a severity (Critical / High / Medium / Low, Critical examples include Art. 50 disclosure absent from a live customer-facing chatbot and DLP scope collapsed so regulated data reaches the AI vendor model; calibrated to the SM-Endpoints L2 tier-treatment matrix; at L1 use a consistent judgment rubric pending SM L2 formalization), a named owner (named engineer, admin, or team owner, not "the IT team"), an SLA (Critical blocker resolved before production cutover or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual), and an after-fix evidence artifact (admin-console screenshot, MDM compliance report, SaaS audit log entry, test record) linked before closure. Findings feed IM-Endpoints as issues for tracking and aging, and loop back to SR-Endpoints where a finding reveals that an REM row's cited evidence was inaccurate, the REM row is updated before the finding is closed. Drift sources verified at L1 without continuous tooling include MDM telemetry (Jamf / Intune / Kandji policy compliance reports), browser admin policy state (Chrome / Edge / Safari admin policy export), SaaS admin audit feeds (M365 / Slack / Workspace / Notion), mobile MDM (app version compliance, model hash, device attestation), and edge device attestation reports.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype IR checklists published, owned, and linked from the SM-Endpoints inventory record and the DR decision record, with the chatbot checklist verifying Art. 50 disclosure in the live UX and the edge device checklist verifying firmware / model signature currency and remote-disable function.
• Deployment, annual, and material-change review triggers wired to the SM-Endpoints inventory; 100% of new AI/HAI-enabled endpoints in the last 90 days have a deployment IR record.
• ≥90% of active AI/HAI-enabled endpoints carry a current-year IR record.
• All Critical / blocker findings resolved before production cutover; High findings closed within 7 days with evidence linked.
• Findings-aging dashboard reviewed at least monthly by the program sponsor.

Maturity Level 2

Objective: Detect configuration drift continuously for Critical and High-tier endpoints via MDM webhook events, browser-policy state monitoring, SaaS-admin webhooks, mobile MDM scan deltas, edge attestation freshness, and vendor admin API recurrent probes; calibrate IR cadence per SM-Endpoints risk tier.

Activities.

A) Continuous drift detection from MDM, browser-policy, SaaS-admin, and device-attestation sources. Wire the following signal sources to an automated drift-detection pipeline for Critical and High-tier endpoints. MDM webhook events: Jamf / Intune / Kandji policy compliance events (DLP rule active or inactive, AI app allowlist changes, device enrollment or unenrollment, compliance policy drift) trigger an automated comparison against the DR-approved MDM policy baseline; material deviations open an IR finding automatically. Browser-policy state monitoring: Chrome / Edge / Safari admin policy state checked on a scheduled basis against the DR-approved extension allowlist and per-extension permission scope; deviations open IR findings. SaaS-admin webhook for new AI feature enabled tenant-wide: M365 / Slack / Workspace / Notion admin event webhooks configured to flag any AI feature enablement event at the tenant or broad-group level; a feature-enablement event without a corresponding open DR approval is a Critical finding. Mobile MDM scan deltas: scheduled mobile MDM scan compares installed app version and model hash against the DR-approved values; version or hash changes since the last scan open IR findings. Edge attestation freshness: edge device attestation report freshness monitored; a device that has not produced a current attestation within the declared window (≤7 days for Critical-tier) opens an IR finding. Detection latency targets: Critical-tier drift detection ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Vendor admin API probing for no-train and data-handling settings. No-train and data-handling settings are probed recurrently via vendor admin APIs for Critical and High-tier endpoints, not trusted from contract language or one-time admin-console screenshots. Amazon Bedrock: AWS Service Control Policy and Bedrock configuration confirming no model fine-tuning on customer data paths and CloudTrail logging active. Google Vertex AI / Gemini: Google Cloud Organization Policy confirming data logging settings and no training-data opt-in active. Azure OpenAI: Azure resource settings confirming data-processing and abuse-monitoring settings match the DR-approved posture. OpenAI (API): Org Settings API confirming data_controls.training_data_sharing is false for applicable API keys. Anthropic: Organization admin settings confirming model training usage terms reflect the no-train commitment. SaaS-AI productivity vendors: M365 Copilot, Slack AI, Workspace AI, and Notion AI admin settings confirming data-scope and training-opt-out settings match the DR-approved posture; admin API where available, UI-based verification with screenshot evidence as fallback. Probing cadence: Critical-tier monthly, High-tier quarterly. Delta from the previous probe opens an IR finding with severity matching the data-class impact of the change. These probes explicitly verify HAI TTP-relevant controls: EA (SaaS-AI feature scope not widened beyond the DR-approved tenant / role / group), AGH (chatbot system-prompt structure unchanged from DR approval), TM (tool-allowlist and output-filter wiring intact), and RA (session and memory bounds for chatbots and assistants unchanged).

C) Tier-calibrated IR cadence. Publish and enforce per the SM-Endpoints L2 tier-treatment matrix: Critical (deployment + semi-annual + material-change-triggered + continuous drift detection); High (deployment + annual + material-change-triggered); Medium (deployment + annual); Low (deployment + re-review on material change). Every endpoint in the SM-Endpoints inventory carries a last-IR-date and next-IR-due field; Critical-tier endpoints with no IR in the last 180 days are escalated to the program sponsor.

Outcome Metrics (L2).

Success Criteria.

• ≥90% of Critical-tier endpoints under continuous drift detection; median detection latency ≤7 days.
• Vendor no-train and data-handling settings verified via admin APIs for ≥80% of Critical/High-tier endpoints on a monthly (Critical) and quarterly (High) probing cadence, not from contract language alone.
• ≥95% of SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR within 24 hours.
• Tier-cadence adherence ≥95%; Critical-tier findings aged per the SM-Endpoints L2 tier-treatment matrix SLAs.

Maturity Level 3

Objective: Operate continuous configuration attestation for Critical-tier endpoints with a daily attestation signal confirming pattern compliance and evidence freshness, automatically open IM tickets on drift, and contribute per-archetype configuration baseline schemas to CSA endpoint working groups, OWASP MASVS, and OASIS.

Activities.

A) Daily attestation signal for Critical-tier endpoints. Each Critical-tier AI/HAI-enabled endpoint produces a daily composite attestation signal covering three dimensions. Pattern compliance: an automated SA-Endpoints-pattern compliance scan confirms key controls are present and active in the deployed configuration, MDM DLP rules match approved scope, browser extension allowlist enforced, SaaS-AI feature state matches DR-approved posture, Art. 50 disclosure confirmed present in live UX via automated probe, and device firmware and model signatures current, using the MDM webhook and SaaS-admin feeds from IR L2 on a daily schedule with machine-readable output. Evidence freshness: the SR-Endpoints REM's evidence citations are checked for staleness against defined freshness windows (vendor admin API probe ≤30 days for Critical / ≤90 days for High; Art. 50 disclosure sample-check ≤7 days for Critical chatbots; kill-switch test ≤90 days; MDM policy compliance report ≤24 hours); stale evidence opens a finding automatically. Configuration within tolerance: deployed configuration (SaaS-AI feature scope, DLP policy state, extension allowlist, device firmware and model hash) is checked against the DR-approved baseline per defined per-control tolerances, minor app version updates within the same approved version range are tolerated; a version change outside the range is not tolerated without DR review; a SaaS-AI feature scope expansion is never tolerated without DR re-review. Attestation artifacts are machine-readable, signed, and stored in the SM-Endpoints inventory record; they are regulator-consumable for EU AI Act Art. 9 risk-management evidence and deployer-duty records per Art. 26. Drift auto-opens an IM-Endpoints ticket carrying the drift dimension (pattern compliance / evidence freshness / configuration), the specific control that failed tolerance, and a link to the DR decision record.

B) Contribute per-archetype configuration baseline schemas. Publish per-archetype IR configuration baseline schemas, defining what correct implementation looks like for each AI/HAI endpoint archetype at each SM-Endpoints tier, to CSA endpoint working groups (reference attestation schema for AI/HAI-enabled endpoint configurations), OWASP MASVS extensions (mobile AI app and browser-based AI tool configuration baselines, with practitioner-level checklist items and evidence-type definitions), and OASIS AI assurance standards (per-archetype endpoint configuration controls mapped to OASIS control categories). Internal practice remains aligned to the published external versions; internal-only deviations are proposed as upstream changes. Adoption is tracked by citations, forks, direct acknowledgment from peer organizations, and inclusion in external tooling or assessment frameworks.

C) Automated drift-to-IM escalation and SLA enforcement. All IR findings, whether from daily attestation or periodic reviews, flow into IM-Endpoints automatically with severity and SLA pre-populated from the SM-Endpoints L2 tier-treatment matrix. The IM-Endpoints SLA clock starts when the finding is opened; overdue Critical findings escalate to the program sponsor automatically at 50% and 100% of the SLA window. Post-incident reviews in IM-Endpoints that touch a configuration control automatically re-examine the IR record for the affected endpoint, was the drift detectable earlier, and what attestation rule would have caught it? The answer updates the attestation rule and the IR checklist.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier endpoints across all three dimensions (pattern compliance, evidence freshness, configuration tolerance); deviations auto-opening IM tickets within 1 hour.
• Zero stale-evidence violations for Critical-tier REMs; High-tier stale-evidence rate trending down.
• Per-archetype configuration baseline schemas published to CSA endpoint working groups, OWASP MASVS, or OASIS with documented external adoption.
• IR reviewer-hours per Critical endpoint per year trending down over two consecutive quarters.

Common Pitfalls

Level 1. - IR treated as a one-time deployment formality, no annual re-review and no material-change trigger; configuration drift accumulates silently for quarters until an audit or an incident surfaces it. - Reviewers take the DR decision record at face value without opening the MDM console or SaaS admin dashboard, the DLP rule is declared in the checklist but never confirmed active in the deployed MDM policy. - Art. 50 disclosure verified from the design mockup rather than the live UX, the disclosure was present in the prototype but removed in a UX refresh before launch. - Vendor no-train settings verified from contract language or DPA text without opening the vendor admin console, the setting can be reset by a vendor product update and the team does not know. - Kill-switch documented in the DR record but never tested, the IR checklist has a kill-switch checkbox that is checked without an actual test execution and a recorded result.

Level 2. - MDM webhook integration exists but generates no findings on policy drift, the webhook fires but automated finding creation was never configured; drift detection is manual in practice. - SaaS-admin webhook is configured for M365 but not for Slack, Workspace, or Notion, new AI feature enablements on those platforms are not detected until the next annual review. - Vendor admin API probing is configured once at onboarding and never re-run, a no-train setting reset by a vendor product update goes undetected for months. - Tier-calibrated cadence exists on paper but Critical and Low-tier endpoints sit in the same review queue with no prioritization, Critical-tier endpoints wait behind Low-tier backlogs. - Drift findings from automated detection dead-end in an alert dashboard rather than auto-opening IM tickets, findings age without owners.

Level 3. - Daily attestation signals show green across all Critical endpoints but the underlying checks cover only MDM enrollment status, DLP rule scope, extension-allowlist enforcement, Art. 50 disclosure, and vendor no-train state are not checked; attestation is cosmetic. - Configuration baseline schemas published externally reflect L1 checklist items only, internal practice has advanced to continuous API probing and SaaS-admin webhooks; external adopters build on a stale baseline. - Attestation-exception queue overwhelms the team because configuration tolerance thresholds are too tight, every minor MDM policy refresh triggers a deviation; reviewers suppress the signal source rather than tune the tolerance rules. - Post-incident IR feedback loop exists in policy but never fires in practice, IM post-incident reviews do not include the IR-record re-examination step; attestation rules never update from incident learning.

Practice Maturity Questions

Level 1. 1. Is there a published, per-archetype IR checklist, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), covering MDM-policy-matches-design verification, config-matches-DR verification, SR REM evidence currency check, logging-flow verification to SIEM, and kill-switch test execution, with the chatbot checklist verifying Art. 50 disclosure in the live UX and the edge device checklist verifying firmware / model signature currency and remote-disable function? Evidence: Published checklists with version history; archetype-specific sections showing the configuration-points verification distinct from DR conformance; sample IR record with screenshot, MDM export, or admin-console evidence attached. 2. Do 100% of new AI/HAI-enabled endpoints going to production in the last 90 days carry a deployment IR record, and do ≥90% of all active endpoints carry a current-year IR record, with material-change triggers wired to SM-Endpoints inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked? Evidence: SM-Endpoints inventory query for last-90-days production entries with IR record IDs; annual review calendar with last-IR dates; findings backlog report showing zero open blockers at deployment and High-finding closure times. 3. Are findings severity-tagged and tracked in IM-Endpoints with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR REM row update before the finding is closed? Evidence: IM-Endpoints backlog export showing severity tags and SLA fields populated; REM update log showing IR-triggered row updates; findings-aging dashboard reviewed by the program sponsor within the last 30 days.

Level 2. 1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints under continuous drift detection, via MDM webhook events, browser-policy state monitoring, SaaS-admin webhooks, mobile MDM scan deltas, and edge device attestation freshness, with median detection latency ≤7 days and automated finding creation on material deviations? Evidence: Drift-detection telemetry report showing per-endpoint signal coverage; detection-latency histogram for Critical-tier; sample auto-generated IR finding linked to an MDM or SaaS-admin webhook event. 2. Are vendor no-train and data-handling settings verified via vendor admin APIs (Bedrock / Vertex / Azure OpenAI / OpenAI / Anthropic / SaaS-AI platforms) on a monthly (Critical) and quarterly (High) probing cadence for ≥80% of Critical/High-tier endpoints, not from contract language alone, with deltas from the previous probe opening IR findings with severity matching the data-class impact? Evidence: Vendor API probing log with cadence dates per endpoint; delta-detection finding showing an admin-console change detected between probes; coverage report showing percentage of Critical/High endpoints covered. 3. Are ≥95% of SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR within 24 hours, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Endpoints L2 tier-treatment matrix SLAs? Evidence: SaaS admin webhook log cross-referenced to IR queue entries with creation timestamps; tier-cadence adherence report from the IR schedule for the last two quarters.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily attestation signal across all three dimensions (pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Endpoints tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs? Evidence: Attestation telemetry dashboard showing daily signal per Critical endpoint for the last 30 days; IM-Endpoints ticket creation log with timestamps within 1 hour of attestation findings; Critical-tier REM evidence freshness report with zero stale entries. 2. Has the program published per-archetype configuration baseline schemas to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical endpoint per year trending down over two consecutive quarters? Evidence: External publication links with adoption indicators (forks, citations, inclusion in external tooling); comparison document showing internal checklist aligned to the published baseline schema; reviewer time tracking report showing QoQ decline. 3. Is the post-incident IR feedback loop operational, IM-Endpoints post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident, ensuring incident learning continuously improves the attestation coverage? Evidence: Sample post-incident review showing IR-record re-examination section completed; attestation rule change log entries linked to incident review IDs; trend showing attestation rule count increasing with incident volume.

22. Security Testing (ST)

Practice Overview

Objective: Prove that every AI/HAI-enabled endpoint and user-facing AI interface behaves correctly under adversarial conditions, by running a foundational per-archetype test battery, maintaining versioned regression corpora, and escalating to scheduled per-tier red-team and continuous adversarial testing at higher maturity levels.

Description: ST-Endpoints exercises the AI/HAI endpoint deployments the organization operates and consumes, AI assistants on managed endpoints, browser-based AI tools, chatbots and conversational UIs, multi-modal AI interfaces, SaaS-AI productivity features, mobile AI apps, and edge AI devices, against a battery of AI-specific test classes tied directly to the threats in the TA-Endpoints library and the requirements in the SR-Endpoints pack. At L1, every archetype has a published test battery (DLP-paste-block, managed-endpoint requirement, tool-allowlist, audit-log completeness, extension-scope, prompt-injection corpus, jailbreak corpus, multi-modal injection corpus, Art. 50 disclosure presence, SaaS-AI silent-enablement detection, app and model signature, edge firmware and remote-disable) plus six versioned regression corpora (prompt-injection, jailbreak, multi-modal injection, DLP-paste-block, browser-extension-scope, Art. 50 disclosure) running on deployment and periodically thereafter. L2 adds per-tier scheduled red-team exercises using TA-Endpoints L2 deep threat models and cross-archetype composition tests (AI assistant + browser extension; chatbot + multi-modal). L3 operates continuous automated adversarial testing and contributes findings to MITRE ATLAS, AVID, OWASP MASVS, OWASP Browser-Extension Top 10, and CSA endpoint working groups.

Context: Classic acceptance test suites exercise the happy path and leave the adversarial path untested. A chatbot passes all functional tests and then follows an injected instruction from a user-crafted input. A browser extension passes its scope review and then reads pages it was not designed to access when a crafted page exploits an over-broad host permission. An AI assistant on a managed endpoint bypasses the tool-allowlist because the enforcement logic was never wired in the deployed configuration. A SaaS-AI feature is enabled tenant-wide and exposes workspace content beyond its intended scope. These failures are invisible to classic testing because classic testing was not designed to enumerate AI-specific failure modes, prompt injection (ATLAS TA0001/TA0003), output-integrity regression (TA0004), data exfiltration via inference (TA0013), and physical-interface attacks (edge AI devices). ST-Endpoints closes this gap by making AI-specific endpoint tests a first-class validation citizen and connecting them directly to the TA threat library so test coverage tracks threat coverage, not just configuration coverage.

Maturity Level 1

Objective: Establish a foundational per-archetype test battery and regression corpora for AI/HAI-enabled endpoints, and verify that every endpoint reaches production with a passed go-deployment battery on record.

Activities.

A) Publish the foundational per-archetype test battery. One test battery per AI/HAI endpoint archetype targeting the top archetype threats from TA-Endpoints and the archetype-specific SR requirements. L1 target: ≤8 named test classes per archetype. Each test class specifies inputs, expected output, pass/fail criteria, an evidence artifact (log snippet, DLP block event, admin-console screenshot, test run record), and the TA threat plus SR requirement it maps to. The AI assistant on managed endpoint battery covers: DLP-paste-block (paste a regulated-data canary into the assistant input field and verify DLP blocks the transfer before content reaches the AI vendor, SR DLP requirement, TA data-exfiltration); managed-endpoint requirement (attempt to install and use the assistant on a non-MDM-enrolled device and verify rejection, SA managed-endpoint pattern); tool-allowlist (attempt a local action not on the declared allowlist and verify the action is blocked at the enforcement layer and logged, SR tool-allowlist requirement, ATLAS TA0004, HAI EA/TM); and audit-log completeness (issue a known invocation and verify required log fields appear within the retention SLA). The browser-based AI tool battery covers extension-scope (load the extension on a page outside its declared host-permission scope and verify the extension cannot read or modify the DOM, OWASP Browser-Extension Top 10), DLP integration, backend SSO rejection of non-SSO credentials, and extension-injection (inject a crafted script into a page the extension processes and verify the extension does not execute or pass it to the backend AI model as instructions, ATLAS TA0001/TA0003, HAI AGH). The chatbot / conversational UI battery covers the prompt-injection regression CI corpus (direct and indirect, run on every deployment update; failure blocks go-live for Critical/High-tier, ATLAS TA0001/TA0003), the jailbreak regression corpus, the data-exfiltration probe corpus (verify the chatbot does not expose cross-user data, system-prompt content, or training-corpus fragments, ATLAS TA0013, OWASP LLM06), Art. 50 disclosure-presence test (verify the disclosure is present in the response or UI at the time of the first interaction on every deployment update and every UX release; failure is a Critical finding), and the escalation-path test. The multi-modal AI interface battery covers image-injection (steganographic prompts), voice-injection, deepfake-detection, and cross-modal consistency (a response safe via one modality but unsafe via another is a Critical finding). The SaaS-AI productivity battery covers silent-enablement detection (trigger a test enablement in a non-production tenant and confirm IR drift detection receives the event within the declared window), data-scope test (attempt to access a workspace section explicitly excluded in the DR record and confirm the feature cannot retrieve it), and regulated-data-flow test (verify DLP blocks regulated data flowing to the vendor AI model before processing). The mobile AI app battery covers app-signature verification (install a modified-signature build and verify rejection), local-model integrity (replace the on-device model and verify hash-mismatch refusal), permission minimization, and biometric-bypass-via-AI (attempt synthetic face or voice authentication and verify rejection). The edge AI device battery covers firmware signature (attempt unsigned firmware flash and verify rejection), model signature (attempt modified model load and verify refusal), physical-tamper test, uplink encryption (capture traffic and verify cipher suite matches the DR-approved specification), and remote-disable (issue the command and verify the AI capability becomes unavailable within SLA). For chatbot, AI assistant, and multi-modal archetypes, the battery explicitly exercises HAI TTPs: AGH (prompt-injection and indirect-injection corpora), EA (tool-allowlist boundary, SaaS-AI data-scope, extension host-permission scope), TM (output filter and tool-call argument validation), and RA (multi-turn session bounds for long-running chatbot and assistant sessions).

B) Build and maintain regression corpora. Six versioned regression corpora in source control, run on deployment and on a periodic cadence. Each corpus entry carries a structured fixture: input, expected safe output pattern, threat tag (HAI TTP + ATLAS tactic ID), OWASP reference, source, and date added. Prompt-injection corpus (30–100 direct and indirect prompt-injection inputs for chatbot, AI assistant, and multi-modal archetypes; covering system-prompt extraction, instruction-override, role-manipulation, multi-turn injection, and indirect injection via user-provided content; run on every deployment update for Critical/High-tier; failure blocks go-live). Jailbreak corpus (30–100 inputs targeting role-override, persona-switch, authority-claim, encoding-bypass, and multi-step reasoning chains; run against chatbot and AI assistant archetypes on every deployment update). Multi-modal injection corpus (20–60 image and audio inputs embedding encoded prompt-injection instructions, steganographic payloads, supersonic embedding, adversarial overlays; run against multi-modal archetypes on every deployment update). DLP-paste-block corpus (20–50 regulated-data canary inputs, credit card patterns, SSN-format strings, synthetic PHI, synthetic source-code fragments, used to verify DLP enforcement at the endpoint boundary; run on periodic cadence and on any DLP policy change). Browser-extension-scope corpus (20–50 crafted page configurations testing that browser-based AI tools cannot read or modify pages outside their declared host-permission scope; run on every extension version update). Art. 50 disclosure corpus (10–20 opening-interaction test fixtures verifying disclosure is present at the first interaction for each customer-facing chatbot and multi-modal interface; run on every UX release). Corpora are versioned in source control with a named corpus owner; corpus refresh cadence is monthly minimum from internal observations (IR findings, IM incidents, red-team results), external public corpora (OWASP LLM Top 10 examples, ATLAS technique examples, OWASP MASVS test cases, public jailbreak research), and sector-specific advisory content. Any deployment adding or modifying AI/HAI endpoint capabilities triggers a corpus completeness check before go-live.

C) Operate the go-deployment battery and wire test failures to IM. Every AI/HAI-enabled endpoint must pass its archetype battery before receiving Sanctioned status in the SM-Endpoints inventory. Go-deployment triggers: pre-production (all applicable archetype tests must pass before the endpoint capability is promoted; the go-deployment test record is linked from the SM-Endpoints inventory); post-model-update (any model version change, firmware update, or app version change triggers a re-run of the applicable archetype battery within 14 days, or within 7 days for Critical-tier); post-incident (any IM-Endpoints incident involving the endpoint triggers a re-run of the relevant battery subset before the incident is closed); quarterly (all active AI/HAI-enabled endpoints re-run their battery; results reviewed by the named test-battery owner). All test failures route to IM-Endpoints within one business day with a severity tag. Named battery owner per archetype is a named role, not a shared-team responsibility.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype foundational test battery published for all seven archetypes (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), linked from the SM-Endpoints inventory record and DR/IR artifacts.
• Six regression corpora published in source control (prompt-injection, jailbreak, multi-modal injection, DLP-paste-block, browser-extension-scope, Art. 50 disclosure), with a named corpus owner and a monthly refresh cadence.
• 100% of AI/HAI-enabled endpoints reaching production in the last 90 days have a passed go-deployment battery on record.
• All test failures routed to IM with a 1-day handoff SLA and named owner.
• Named battery owner per archetype; automation covers ≥60% of battery items.

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Endpoints L2 tier-treatment matrix, run scheduled per-tier red-team exercises for Critical (quarterly) and High (semi-annual) endpoints, and test cross-archetype compositions for Critical-tier endpoints.

Activities.

A) Tier-calibrated test battery and corpus depth. Publish a per-tier test treatment aligned to SM-Endpoints L2's tier-treatment matrix. Critical tier: full archetype battery at go-deployment with executive sign-off on results; all six corpora running on every deployment update; post-model-update re-run within 7 days; Art. 50 disclosure automated probe on every UX release with failure as P1; DLP-paste-block verified quarterly by ST with findings routed to IM within 1 business day. High tier: full archetype battery; all six corpora on deployment plus periodic re-runs; post-model-update re-run within 14 days; Art. 50 disclosure automated probe on every UX release; DLP-paste-block verified semi-annually. Medium tier: subset battery (top-4 threat classes); prompt-injection and jailbreak corpora on deployment; post-model-update subset re-run within 30 days; Art. 50 disclosure verified at go-deployment and annually; DLP-paste-block verified annually. Low tier: spot-check (3 test classes); prompt-injection corpus on deployment; output-integrity check at next quarterly; Art. 50 disclosure and DLP-paste-block verified at go-deployment.

B) Scheduled per-tier red-team exercises using TA-Endpoints L2 threat models. Red-team cadence by tier: Critical (quarterly, 4 per year, scope derived from TA-Endpoints L2 per-artifact deep threat model, covering prompt-injection chains, indirect prompt injection via user-provided content, DLP bypass attempts, Art. 50 disclosure circumvention, tool-allowlist escape for AI assistants, extension-scope violation for browser tools, data-exfiltration via AI completions, physical-interface attacks for edge devices, biometric-bypass via synthetic media for mobile apps, and silent SaaS feature enablement); High (semi-annual, 2 per year, scope from TA-Endpoints L2 artifact deltas, covering the top-5 threats from the per-artifact model); Medium/Low (ad-hoc before major configuration changes or scope expansions, archetype snapshot driving scope). Each exercise follows the HAIAMM AI Security Testing methodology: written rules of engagement, test plan reviewed with the endpoint owner, execution log, structured findings report (severity, root cause, ATLAS tactic ID, SR requirement traced, remediation pairing). Critical/High-severity red-team findings produce corpus entries within 30 days. Cross-archetype composition tests for Critical-tier: AI assistant + browser extension (browser extension passes content to the AI assistant containing injected instructions; verify the assistant does not follow them and the DLP policy covers the combined data-flow path, HAI AGH/EA); chatbot + multi-modal (submit a multi-modal input to a chatbot interface; verify the cross-modal safety filter applies consistently, Art. 50 disclosure is present regardless of modality, and indirect prompt injection via image content does not redirect the text-response path).

C) Red-team findings to corpus pipeline. Every Critical or High-severity red-team finding produces: a new corpus entry (input, expected safe output, threat tag, ATLAS tactic ID, date, source reference) committed to the relevant regression corpus within 30 days; an IM-Endpoints finding with severity tag and the named endpoint owner as assignee; and a TA-Endpoints library-gap ticket if the finding was not in the archetype library, tracked with a named owner and a 30-day close SLA for Critical-tier gaps. This pipeline ensures every quarterly red-team exercise produces durable coverage for the findings it surfaces.

Outcome Metrics (L2).

Success Criteria.

• Quarterly red-team for 100% of Critical-tier endpoints; semi-annual for 100% of High-tier; scope tied to TA-Endpoints L2 per-artifact deep threat models.
• Critical-tier regression corpora (all six) running on every deployment update; per-tier calibration enforced.
• ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days.
• Cross-archetype composition tests documented and run for all Critical-tier composite endpoints.
• Per-tier SLA adherence for testing activities ≥90%.

Maturity Level 3

Objective: Operate continuous automated adversarial testing for Critical-tier endpoints, publish regression corpora and findings as open artifacts, and contribute discovered TTPs to MITRE ATLAS, AVID, OWASP MASVS, OWASP Browser-Extension Top 10, and CSA endpoint.

Activities.

A) Continuous automated adversarial testing harness. Deploy an automated adversarial testing harness that runs daily against all Critical-tier AI/HAI-enabled endpoints. Prompt-injection generator: produces novel direct and indirect prompt-injection inputs using mutation of the regression corpus, template-based variation, and generated jailbreak-ladder sequences; runs against chatbot, AI assistant, and multi-modal archetypes; confirms output filters and prompt-injection defenses remain active (ATLAS TA0001/TA0003; HAI AGH). Multi-modal injection seeder: generates image and audio inputs embedding adversarial instructions (steganographic payloads, supersonic audio embedding, adversarial overlay generation); exercises the multi-modal input validation and safety-filter paths. DLP-bypass generator: generates regulated-data canary variants (encoding variations, tokenization-splitting attempts, homoglyph substitution) designed to evade DLP pattern-match rules; verifies DLP enforcement is robust against common evasion patterns. Extension-scope probe: generates crafted page configurations and cross-origin access attempts that exercise browser extension host-permission enforcement. Art. 50 disclosure monitor: automated daily probe of all live customer-facing chatbot and multi-modal interfaces confirming AI disclosure is present at the first interaction; any interface where disclosure is absent generates a P1 finding to IM-Endpoints within 1 hour. Findings are triaged by a named ST owner at least weekly. Novel TTPs, patterns not in the TA-Endpoints library, are fed into the TA L3 auto-proposal pipeline within 14 days. High-severity automated findings route to IM-Endpoints within 24 hours.

B) Contribute findings to industry. Contribute anonymized, legally-vetted findings to MITRE ATLAS (novel prompt-injection technique observations for endpoint-specific surfaces, voice injection, image embedding, browser-extension injection chains, following ATLAS evidence-and-provenance requirements; target ≥4 contributions per year), AI Vulnerability Database (AVID) (structured disclosure submissions for novel vulnerabilities in AI/HAI endpoint deployments or their upstream AI vendors with coordinated disclosure where third-party components are involved), OWASP MASVS (real-world test evidence for mobile AI app security requirements; target ≥2 substantive submissions per revision cycle), OWASP Browser-Extension Top 10 (real-world telemetry evidence for browser-based AI tool attack surface during revision cycles), and CSA endpoint working groups (anonymized findings and test patterns for managed-endpoint and SaaS-AI feature attack surfaces; participation in joint red-team benchmarking exercises).

C) Publish regression corpora and test patterns as open artifacts. Publish anonymized versions of all six regression corpora (prompt-injection, jailbreak, multi-modal injection, DLP-paste-block, browser-extension-scope, Art. 50 disclosure) under an open license, scrubbed of org-specific endpoint names, data classes, and identifiers. Maintain the published versions upstream; internal corpora are a superset of the published versions with org-specific entries not shared externally. Host or co-host at least one industry endpoint AI red-team benchmark per year (OWASP AI chapter, CSA endpoint working group, or sector ISAC AI red-team exercise); collect cross-org detection-benchmark improvement data from participants.

Outcome Metrics (L3).

Success Criteria.

• ≥80% of Critical-tier AI/HAI-enabled endpoints under continuous automated adversarial testing with daily probe execution; novel TTPs triaged into the TA-Endpoints library within 14 days; high-severity findings routed to IM within 24 hours.
• ≥4 industry contributions per year to MITRE ATLAS, AVID, OWASP MASVS, OWASP Browser-Extension Top 10, or CSA endpoint.
• All six open regression corpora published under a permissive license and maintained upstream.
• Art. 50 disclosure daily probe covering 100% of in-scope customer-facing interfaces; ≥1 hosted industry endpoint AI red-team benchmark per year plus ≥2 participated.

Common Pitfalls

Level 1. - Test battery reduced to a logging-completeness check and a functional happy-path assertion, no adversarial probes (prompt injection, DLP-paste-block, Art. 50 disclosure check, extension-scope test) are actually exercised. - Regression corpora committed to source control but not wired into the deployment pipeline, they exist but run only when a reviewer manually triggers them; coverage erodes after every update cycle. - Art. 50 disclosure test runs once at go-deployment but is never re-run after UX releases, a UX refresh removes the disclosure; the absence goes undetected until a regulator or user reports it. - Go-deployment battery runs once pre-production but is never re-run after model-version updates, firmware updates, or app version changes. - Test failures logged in a spreadsheet separate from IM, no SLA enforcement, no aging visibility, no named owner; the same failure recurs across multiple deployments undetected. - Test battery conflates chatbot and AI assistant, chatbot-specific tests (Art. 50 disclosure, escalation path, prompt-injection corpus) are absent because the same checklist was applied to both archetypes.

Level 2. - Red-team scope defined as "prompt-injection probes" but indirect injection via user-provided image content, DLP bypass attempts, Art. 50 disclosure circumvention, and cross-archetype composition failures are excluded, the top threat classes for chatbot + multi-modal compositions go untested. - Per-tier calibration documented in the tier-treatment matrix but the deployment pipeline applies the same corpus to all tiers, Critical endpoints run the same tests as Low; differentiation exists on paper only. - Red-team findings route to IM but the finding-to-corpus pipeline is never executed, 12 months of Critical/High findings sit in IM as closed tickets with no corpus entries; the same vulnerabilities are re-discovered at the next exercise. - Cross-archetype composition tests scoped but not executed because no team owns AI-assistant-plus-browser-extension testing, composition-specific failure modes are in the threat model but not in any test.

Level 3. - Continuous harness runs prompt-injection probes that the chatbot's output filter trivially blocks, coverage metric looks good but the probes are not exercising real novel attack surfaces. - Art. 50 disclosure daily probe covers only the initial interaction of the primary chatbot, SaaS-AI productivity features and multi-modal interfaces on secondary surfaces are not probed; a disclosure gap persists undetected. - Industry contributions are legal-vetted case-study summaries rather than actionable, reproducible technique descriptions, ATLAS reviewers cannot map them to a technique ID; OWASP MASVS submissions lack reproducibility notes. - Open corpora published once and then not maintained, external organizations build on a stale version while the internal corpus has 60 new entries; discrepancies surface at community exercises.

Practice Maturity Questions

Level 1. 1. Is a per-archetype foundational test battery published for all seven AI/HAI endpoint archetypes, with each test class tied to a TA-Endpoints archetype threat (HAI TTP + ATLAS tactic ID) and an SR-Endpoints requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI-enabled endpoints required to pass the battery before production Sanctioned status is issued? Evidence: Published battery documents per archetype with TA-threat and SR-requirement traceability table; SM-Endpoints inventory showing Sanctioned entries with passed go-deployment battery records linked; sample test run with evidence artifact attached. 2. Are six regression corpora (prompt-injection, jailbreak, multi-modal injection, DLP-paste-block, browser-extension-scope, Art. 50 disclosure) versioned in source control, with a named corpus owner, a monthly refresh cadence from internal and external sources, and runs triggered on deployment updates for Critical/High-tier endpoints, and is the Art. 50 disclosure corpus re-run on every UX release for customer-facing chatbots and multi-modal interfaces? Evidence: Source-control repository showing six corpus directories with version history and corpus owner in CODEOWNERS; deployment-pipeline configuration showing corpus run results per deployment for the last 30 days; monthly corpus refresh commit log. 3. Are all test failures routed to IM-Endpoints within 1 business day with a severity tag and named owner, and does TA-Endpoints archetype threat coverage by the test battery and corpus reach ≥80% by end of year one? Evidence: IM-Endpoints query for ST-originated issues with creation timestamps within 24 hours of test failure; threat-coverage matrix mapping TA archetype threats to battery test classes and corpus entries showing ≥80% coverage ratio.

Level 2. 1. Are 100% of Critical-tier AI/HAI-enabled endpoints red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Endpoints L2 per-artifact deep threat models, covering prompt-injection chains, multi-modal injection, DLP bypass, Art. 50 disclosure circumvention, tool-allowlist escape, extension-scope violation, data-exfiltration probes, and physical-interface attacks for applicable archetypes, with findings routed to IM and remediation tracked? Evidence: ST records showing red-team exercise dates per Critical and High-tier endpoint for the last 12 months; red-team report for the most recent Critical-tier exercise showing scope sourced from the TA-Endpoints L2 per-artifact model; IM-Endpoints findings linked from the report. 2. Is per-tier corpus calibration enforced (Critical-tier: all six corpora on every deployment update; Low-tier: prompt-injection corpus on deployment), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? Evidence: Deployment-pipeline configuration showing per-tier corpus routing; pipeline telemetry confirming all six corpora ran for Critical-tier deployments; finding-to-corpus pipeline telemetry showing conversion rate and lead times. 3. Are cross-archetype composition tests (AI assistant + browser extension; chatbot + multi-modal) documented and executed for all Critical-tier composite endpoints, and is per-tier SLA adherence for testing activities ≥90%? Evidence: Composition test plans per Critical-tier composite endpoint; execution logs with pass/fail results; per-tier SLA adherence report from program telemetry for the last two quarters.

Level 3. 1. Are ≥80% of Critical-tier AI/HAI-enabled endpoints under continuous automated adversarial testing with daily probe execution, covering prompt injection, multi-modal injection, DLP-bypass generation, extension-scope probing, and Art. 50 disclosure monitoring, with novel TTPs triaged into the TA-Endpoints library within 14 days and high-severity automated findings routed to IM within 24 hours? Evidence: ST harness telemetry showing daily probe execution per Critical endpoint; harness-to-TA-library pipeline log with lead time per novel TTP; IM-Endpoints high-severity finding creation timestamps within 24 hours of automated detection. 2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, OWASP MASVS, or OWASP Browser-Extension Top 10, and are all six open regression corpora published under a permissive license and maintained upstream with documented external adoption? Evidence: Contribution log with external submission links and acceptance confirmation from ATLAS, AVID, OWASP MASVS, or OWASP Browser-Extension Top 10; open-source repository links for the six published corpora with commit history showing active maintenance; legal review records for each submission. 3. Is the Art. 50 disclosure daily probe covering 100% of in-scope customer-facing chatbot and multi-modal interfaces, and has the program hosted at least 1 industry endpoint AI red-team benchmark per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data? Evidence: Automated probe telemetry showing daily coverage of all in-scope customer-facing interfaces; exercise log with hosted and participated entries for the last 12 months; post-exercise report showing detection-benchmark data collected from participants.

23. Environment Hardening (EH)

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 surfaces that seven AI/HAI endpoint archetypes create: AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, AI-augmented productivity (SaaS-AI on endpoint), mobile AI app, and 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-extension 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 integrity attestation, secure enclave usage, 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, and 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 never 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 ships to customers without an EU AI Act Art. 50 disclosure because the UX was never centrally templated. A SaaS vendor silently enables an AI-summarization feature tenant-wide; the feature ingests emails including customer contracts, and nobody notices because SaaS-admin governance covers identity and permissions but not AI-feature enablement. A mobile AI app performs on-device inference with an unsigned model that has been quietly swapped through a side-loaded update. An edge AI device is physically tampered with and continues to operate with a compromised firmware because the device's secure boot policy was not enforced at runtime. 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 the SM-Endpoints inventory enumerates. The HAI TTPs EA, AGH, TM, and RA are mitigated here at the perimeter level: EA via the MDM allowlist and SaaS-admin AI-feature governance; AGH via the multi-modal input-validation rule and the chatbot output-filter configuration; TM via tool-scope restrictions on copilots and assistant runtime policy; RA via session-bounded mobile and edge integrity attestation that prevents drifted local models from being trusted.

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.

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. SSO + MFA is 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 to org-domain identities is disabled; conditional-access policy requires managed-device posture (MDM-enrolled, compliant) before granting AI console sessions. Browser policy and DLP prevent employees from authenticating to consumer AI services with a personal account while org data is present in the browsing context; org-issued AI service accounts are the only sanctioned credential path. 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. 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 is tuned for the patterns specific to AI/HAI endpoint use, regulated-PII paste into LLM prompt fields, bulk customer-data export via AI assistant, source-code paste outside the approved coding assistant, and bulk personal-data queries via AI assistant, with rules that alert or block based on data class. EDR is configured with process-behavior signatures tuned to AI-data-exfiltration patterns such as LLM-client-process network connections to unapproved AI provider endpoints, bulk file upload from a system to an AI API endpoint, and browser-extension processes accessing sensitive local files while initiating AI provider API calls. 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. 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 SM-Endpoints intake; any AI feature found active without intake approval is a shadow-AI finding routed to IM-Endpoints.

B) Harden the data-flow envelope. 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. 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. 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. Classification-aware routing is enforced through the egress path; sessions that carry mixed classification (a Confidential paste alongside Internal context) route to the most restrictive applicable rule.

C) Harden the mobile/edge integrity and customer-facing envelopes. 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. Edge AI devices managed by the organization ship with signed firmware; the firmware signing certificate lives in the secrets vault; unsigned firmware is rejected at boot by the device's secure boot policy. 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. 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. 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 an MDM quarantine action. 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. 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. 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. Customer-facing chatbot and multi-modal AI interface outputs are filtered against a brand-safety ruleset before delivery; the filter configuration is reviewed quarterly by the Legal and Brand teams.

Outcome Metrics (L1).

Success Criteria.

• 100% of AI/HAI endpoint archetypes in the SM-Endpoints inventory have a named baseline hardening status across the five envelope dimensions; 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 on managed endpoints and managed browsers.
• SSO + MFA enforced on all AI consoles accessed 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 confirmed by ST-Endpoints test; 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 with an annual recurrent verification schedule in place.

Maturity Level 2

Objective: Calibrate hardening depth per SM-Endpoints L2 risk tier, Critical customer-facing endpoints get dedicated rate-limit and abuse-detection profiles, Critical AI assistant use enforces managed-endpoint requirement at the identity layer, Critical edge devices use HSM-backed attestation, and SaaS-admin AI-feature governance is enforced as IaC; Medium and Low-tier archetypes remain on the L1 baseline.

Activities.

A) Tier-conditional hardening calibration. Publish and enforce a hardening tier-treatment matrix aligned to the SM-Endpoints L2 risk-tier rubric. Critical: managed-endpoint requirement enforced at the identity layer through conditional-access policy (unmanaged devices blocked); per-archetype MDM policy with real-time enforcement; DLP content inspection on AI prompt fields with block-on-regulated-data; dedicated rate-limit profile and dedicated abuse-detection ruleset per customer-facing endpoint; EU AI Act Art. 50 disclosure tested in the ST battery per release with disclosure failure as a deployment blocker; signed app plus signed model with MDM reporting integrity failure within 1 hour; HSM-backed edge attestation with physical-tamper detection and IM alert routing; SaaS-AI-feature enablement expressed as IaC with deviations becoming IM findings. High: MDM enrollment required and monitored; MDM allowlist enforced; enhanced AI-specific DLP rules with alert plus block; shared abuse-detection with elevated thresholds; Art. 50 disclosure tested quarterly; signed app plus signed model verified at launch; TPM-backed edge attestation with boot-time integrity; approval-gated SaaS intake with quarterly audit. Medium: MDM enrollment preferred; standard AI-specific DLP rules; standard rate-limit; Art. 50 disclosure deployed; signed app and model-hash check; software-TPM edge attestation with periodic integrity check; approval-gated SaaS intake. Low: baseline L1 controls. Each endpoint archetype record in the SM-Endpoints inventory carries its tier's hardening status; gaps between required and actual controls become open IM-Endpoints findings with an SLA matching the archetype's tier.

B) Critical customer-facing endpoint hardening and identity-layer managed-endpoint enforcement. 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; thresholds are reviewed quarterly against actual traffic baselines and adjusted before abuse patterns can destabilize the endpoint. 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 thresholds are reviewed monthly. For Critical-tier AI assistant and copilot endpoints that access regulated data or perform consequential actions, conditional-access policy at the IdP (Azure AD Conditional Access, Okta Device Trust, Google BeyondCorp, or equivalent) enforces MDM-enrolled, MDM-compliant device posture before granting the session; 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 AI IaC. Critical-tier edge AI devices use an HSM (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 sealed PCR values at each boot; attestation failures route to IM-Endpoints within 5 minutes. The HSM seals the system state; any physical attempt to access device internals triggers an HSM-detected tamper event that routes to IM-Endpoints and initiates remote-disable if the device is network-accessible. 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; deviations between the declared IaC configuration and the live SaaS admin console state are 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).

Success Criteria.

• 100% of Critical-tier AI assistant endpoints enforce the 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 operate under dedicated rate-limit and abuse-detection profiles reviewed quarterly against traffic baselines.
• 100% of Critical-tier edge AI devices use HSM-backed attestation with 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 with tier-appropriate SLAs.

Maturity Level 3

Objective: Express all EH-Endpoints controls as MDM, browser-policy, and SaaS-admin IaC modules; drive adaptive policy tightening from ML-Endpoints detections and IM-Endpoints incidents; auto-provision tier-appropriate hardening for new archetypes; contribute hardening baselines to CIS, CSA, OWASP MASVS, OpenSSF AI, and sector ISACs.

Activities.

A) Hardening-as-code. Every EH-Endpoints control is expressed as a version-controlled, forkable IaC module parameterized by archetype and tier: an identity envelope module (IdP conditional-access policy module covering managed-endpoint device-posture requirement, MFA enforcement, personal-account prohibition rule, AI-console session scope) applied at the IdP configuration layer; an endpoint-runtime module (MDM configuration profiles for AI-tool allowlist, app blocking, browser-extension allowlist, screen-capture policy for AI sessions) deployable via Intune, Jamf, or equivalent MDM API, together with DLP rule configuration and managed-browser policy templates; a 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); a mobile/edge integrity module (mobile app signing policy, local-model hash registry and launch-time attestation rule, edge device attestation policy with HSM configuration, sealed PCR value registry, tamper-alert routing) deployable via MDM and edge device management console APIs; and a customer-facing module (per-archetype rate-limit configuration with parameterized threshold table, abuse-detection rule library, EU AI Act Art. 50 disclosure template registry, brand-safety filter configuration). Modules are 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 an AI console, rate-limit removed from a Critical-tier chatbot, edge attestation policy deleted) triggers a human-review alert within 2 business days and opens 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. A regulated-data paste-attempt volume spike produces a DLP rule sensitivity increase proposal for the affected archetype; a customer-facing chatbot abuse-pattern detection at scale produces a rate-limit tightening proposal and a prompt-injection corpus update proposal; a SaaS-AI feature silently enabled produces a SaaS-admin IaC rollback proposal and an intake-amnesty trigger; an edge-device integrity failure rate above threshold produces an attestation policy tightening proposal (reduced attestation interval, additional PCR sealing); a mobile-app local-model integrity failure cluster produces a model signing re-pin proposal and an MDM force-update trigger proposal. Post-incident review records that identify a hardening gap produce a hardening-baseline update proposal; a Critical-tier incident involving a DLP bypass produces a DLP rule tuning proposal with the IM incident reference. Proposals are human-reviewed by a security platform engineer before deploy; 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. Hardening changes that reflect a new threat pattern are fed back to TA-Endpoints as candidate new threat entries and to SR-Endpoints as candidate new requirements, the adaptive loop is bidirectional. Auto-provisioning fires on SM-Endpoints inventory registration: when a new AI/HAI endpoint archetype is registered, the IaC automation provisions its tier-appropriate hardening profile within 24 hours of registration.

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), to OWASP MASVS (mobile AI app signing and local-model integrity attestation controls, on-device model integrity verification requirements, secure enclave usage for sensitive AI operations), to CIS benchmarks for AI/HAI endpoint hardening (MDM allowlist patterns, browser-extension governance), to OpenSSF AI (endpoint hardening reference patterns for AI consumer software), and to sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), 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; contributions are maintained upstream and the internal practice aligns with the published external version.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of EH-Endpoints controls expressed as authoritative 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; every change traceable to a source signal; downstream endpoint and product teams notified within 24 hours of a tightening change.
• 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, CIS, OpenSSF AI, sector ISACs) with documented adoption.

Common Pitfalls

Level 1. - MDM AI-tool allowlist deployed but not enforced at the browser layer, an employee installs a consumer AI browser extension that is not on the allowlist; the MDM blocks app installation but has no visibility into browser-extension installs and 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 retested, a chatbot update removes the disclosure step because a sprint team treated it as a bug fix; the regression is discovered six months later when a regulator reviews a complaint. - 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 and regulated data has been flowing to training for 90 days before the annual IR review catches it.

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 with org SSO credentials (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 and the HSM attestation becomes 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 drift detection or an IM finding.

Level 3. - IaC coverage declared at ≥90% but the registry counts 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 and 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 re-tier 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.

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 deployed and actively monitored on ≥95% of managed endpoints? Evidence: SM-Endpoints inventory record per archetype showing hardening status; MDM compliance dashboard; DLP management console rule export. 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? Evidence: IdP conditional-access policy export; SM-Endpoints inventory × IR review records with no-train confirmation dates. 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? Evidence: ST-Endpoints disclosure test results; MDM telemetry on signed app/model verification; edge device attestation telemetry.

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, 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? Evidence: IdP conditional-access policy audit × SM inventory; rate-limit configuration registry showing per-archetype Critical-tier profiles. 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? Evidence: device attestation telemetry; IaC registry × SaaS admin audit drift records. 3. Is a tier-hardening matrix published and enforced at provisioning across all five envelope dimensions per the SM-Endpoints L2 tier-treatment matrix, with gaps between required and actual controls tracked as open IM-Endpoints findings with tier-appropriate SLAs? Evidence: published tier-hardening matrix; provisioning-gate configuration; IM-Endpoints backlog showing open hardening-gap findings per archetype.

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? Evidence: IaC registry inventory; drift-detection telemetry; auto-remediation rate; change-log export consumable by downstream MDM and SaaS admin teams. 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? Evidence: adaptive-policy change log with ML/IM source references; human-approval records; downstream-team notification log. 3. Does the program contribute ≥2 AI/HAI endpoint hardening baselines per year to industry bodies (CSA AI Safety Initiative, OWASP MASVS, CIS, OpenSSF AI, 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? Evidence: contribution log with upstream adoption references; auto-provisioning telemetry tied to SM-Endpoints registration events.

24. Issue Management (IM)

Practice Overview

Objective: Run a single unified backlog and a single tier-calibrated incident playbook for every AI/HAI endpoint issue the organization deploys or governs, findings from TA-Endpoints, SR-Endpoints, DR-Endpoints, IR-Endpoints, ST-Endpoints, ML-Endpoints, and external advisories, with named owners, tier-aware SLAs, AI-specific containment plays for the seven primary endpoint incident classes, and regulatory SLA tracking that never misses a notification window because of organizational diffusion.

Description: IM-Endpoints is the clearinghouse for everything the other Endpoints-domain practices produce. Every TA-Endpoints threat snapshot row that carries residual risk, every SR-Endpoints REM accepted gap, every DR-Endpoints approve-with-conditions item, every IR-Endpoints drift finding, every ST-Endpoints test failure or red-team finding, every ML-Endpoints detection alert, and every external advisory (vendor SaaS-AI advisories, browser extension store flags, mobile app store security flags, edge-device CVEs, MITRE ATLAS endpoint-technique updates) flows into a single prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous incident playbook. The playbook contains AI-specific endpoint containment plays, regulated-data egress via AI assistant (endpoint-isolate, DLP-rule-tune, GDPR Art. 33 evaluation), unsanctioned browser extension (extension force-remove, data-flow assessment), SaaS-AI silent-enablement (feature-disable, intake-amnesty, GDPR Art. 33 evaluation), chatbot abuse / jailbreak at scale (rate-limit tighten, prompt-injection corpus update), multi-modal injection (input-validation tighten, output-filter update), mobile-AI integrity failure (MDM force-update, model re-pin), and edge-device tamper (remote-disable, firmware re-attestation). Pre-established escalation paths cover CISO, Privacy/Legal, Communications, executive sponsor, and regulator routing. Every Critical/blocker incident receives a post-incident review whose outputs feed back to SA-Endpoints (pattern update), SR-Endpoints (requirements-pack update), EG-Endpoints (training content), and ML-Endpoints (detection update). The regulatory SLA tracker ensures GDPR Art. 33 72-hour breach notification, EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73 serious-incident reporting, HIPAA, PCI-DSS, COPPA, FERPA, and sector-specific windows are never missed.

Context: Without a unified backlog, AI/HAI endpoint issues scatter across MDM dashboards, DLP alert queues, SaaS-admin change logs, mobile-device security consoles, edge device management platforms, and product-team backlogs. A browser extension force-installed by a user that bypassed MDM policy sits in the MDM event log for two weeks before anyone recognizes it as a data-exfiltration risk. A SaaS vendor's AI feature is silently enabled by an admin; the privacy team finds out when a GDPR data-subject inquiry mentions AI-processed emails. A chatbot jailbreak campaign runs over a weekend; the ML-Endpoints alert fires but routes to a queue nobody checks until Monday. An edge device with failed attestation continues to operate because the tamper alert routed to a ticketing system with no on-call owner. The GDPR Art. 33 72-hour clock starts at the moment the organization becomes aware of a personal-data breach, not when the responsible team processes the notification. EU AI Act Art. 73 imposes serious-incident reporting obligations on Annex III high-risk endpoint systems. HIPAA breach-notification windows and sector mobile-banking notification rules apply when AI/HAI endpoints process the regulated data classes. IM-Endpoints closes all of these gaps with a single backlog, one triage rubric, AI-specific endpoint incident classes named in advance, and a regulatory SLA tracker that escalates automatically as clocks approach expiry.

Maturity Level 1

Objective: Operate a single unified AI/HAI endpoint issue backlog with a standard triage rubric, an AI-specific incident playbook covering the seven primary endpoint incident classes, and regulatory SLA tracking for GDPR Art. 33, EU AI Act Art. 50 and Art. 73, HIPAA, PCI-DSS, COPPA, FERPA, and sector-specific obligations.

Activities.

A) Stand up the AI/HAI endpoint issue backlog and triage rubric. One backlog with standardized metadata per issue: source (TA-Endpoints / SR-Endpoints / DR-Endpoints / IR-Endpoints / ST-Endpoints / ML-Endpoints / external, vendor SaaS-AI advisory, browser extension store flag, mobile app store security flag, edge-device CVE, MITRE ATLAS endpoint-technique update, customer report), affected archetype(s) linked to the SM-Endpoints inventory with archetype and tier, severity (Critical / High / Medium / Low anchored to AI-endpoint-specific axes), named owner from the SM-Endpoints inventory with escalation path to the program sponsor, SLA target, evidence link to the originating artifact, and a regulatory flag indicating whether the issue carries a notification obligation (GDPR Art. 33 clock started, EU AI Act Art. 50 transparency failure identified, EU AI Act Art. 73 clock started, HIPAA breach-notification triggered, PCI-DSS endpoint breach identified, COPPA or FERPA implication, sector-specific). The AI-endpoint-specific severity rubric: Critical means regulated data actively exfiltrated via an AI/HAI endpoint, a chatbot or multi-modal AI interface operating without Art. 50 disclosure at scale, an edge AI device physically tampered with and continuing to operate, a personal-data breach via an AI endpoint triggering GDPR Art. 33, a mobile AI app serving a compromised local model to a large user cohort, or a SaaS-AI feature processing regulated data without approved data-scope; High means a confirmed control failure in a production AI/HAI endpoint archetype with potential for harm (DLP allow event for regulated customer data to an AI assistant, unsanctioned browser extension with data-access permissions installed on ≥10 endpoints, edge device attestation failure with network access, chatbot jailbreak campaign at scale with customer-facing impact, SaaS-AI feature enabled tenant-wide without intake where regulated data may be in scope); Medium covers confirmed gaps in non-production or compensating-control-protected production archetypes and SR-Endpoints REM accepted gaps past expiry; Low captures informational items, Low-tier logging gaps, and edge-device CVEs not yet assessed for applicability. Published SLAs: Critical acknowledge ≤4h / contain ≤48h / root-cause ≤30d; High ack ≤24h / contain ≤7d / root-cause ≤45d; Medium ack ≤48h / remediate ≤14d; Low ack ≤5 business days / remediate ≤30d. Triage cadence: daily for Critical and new High; weekly for Medium; monthly aging review for the full backlog.

B) Publish the AI-specific endpoint incident playbook. Publish playbook entries for the seven primary AI/HAI endpoint incident classes. Each entry names trigger conditions, pre-assigned roles (endpoint-security on-call, Privacy/Legal contact, SaaS-admin owner, executive sponsor escalation path, CISO and Communications routing for Critical-tier customer impact), step-by-step containment, artifacts to collect, evidence-capture instructions for the deployer-duty record, closure criteria, and SLA targets. Regulated-data egress via AI assistant: triggered by ML-Endpoints detection of a DLP-allow event where the data class is regulated and the destination is an AI tool endpoint, containment is endpoint-isolation of the affected managed endpoint from AI provider network access via MDM policy update, scope assessment (principal, AI tool, data class, volume), DLP rule confirmation and tuning, and Privacy/Legal routing for GDPR Art. 33 evaluation with the clock starting at ML-Endpoints detection time if breach is plausible. Unsanctioned browser extension: triggered by an extension-install event where the extension ID is not in the SM-Endpoints allowlist, containment is extension force-remove via MDM browser policy update, extension blocklist update to prevent reinstall, data-flow assessment of the permissions granted, user coaching referral to EG-Endpoints, and Privacy/Legal escalation if data-transfer events indicate regulated data may have been transmitted. SaaS-AI silent-enablement (shadow AI in SaaS): triggered by a SaaS-admin AI feature-enablement event with no matching SM-Endpoints intake record, containment is feature-disable or scope-reduction pending intake review, full SaaS-admin audit log review (who enabled it, via which mechanism, when), intake-amnesty path through SM-Endpoints, data-scope assessment of what the feature processed while active without approval, and GDPR Art. 33 / Art. 28 evaluation if regulated data flowed. Chatbot abuse / jailbreak at scale: triggered by ML-Endpoints abuse-detection events at volume above threshold or by ST-Endpoints chatbot-abuse red-team findings in production, containment is rate-limit tightening for the affected endpoint, prompt-injection corpus update to capture the confirmed patterns, output-filter tuning for any new output patterns observed, customer-impact assessment from session logs across the abuse window, and customer communication per the Legal-reviewed template if the campaign produced unsafe outputs at scale. Multi-modal injection: triggered by an output safety-filter event indicating injected or unsafe content originating from a multi-modal input or by an ST-Endpoints multi-modal injection finding, containment is modality-specific input-validation tightening for the modality that enabled the injection, output safety-filter update, regression-corpus update, and customer-impact assessment with communication if injected outputs were delivered. Mobile-AI integrity failure: triggered by an ML-Endpoints local-model integrity event with result fail, containment is app force-update via MDM to restore a known-good app version, local-model signature re-pin, affected-installs assessment (how many devices, which principal cohort, how long the failure was present), assessment of whether the compromised model produced customer-affecting outputs, and EU AI Act Art. 26 / Art. 50 implications evaluation if customer-affecting outputs originated from a compromised model. Edge-device tamper: triggered by a physical-tamper event or a boot-attestation event with result fail on a Critical-tier edge AI device, containment is immediate remote-disable, dispatch of the physical-recovery team per the SOP, firmware re-attestation after physical inspection and any required re-flash, affected-data assessment for data processed between tamper event and remote-disable, and the SM-Endpoints device record update with the incident reference and re-attestation confirmation.

C) Track regulatory SLAs and run post-incident reviews. The regulatory SLA tracker is live with named obligations and automated escalation as deadlines approach. GDPR Art. 33: 72-hour supervisory-authority notification after the controller becomes aware of a personal data breach; clock starts on the first internal alert that constitutes awareness (ML-Endpoints detection, IR-Endpoints finding, external notification); named owner Privacy/Legal; any GDPR Art. 33 clock started from an AI/HAI endpoint incident is flagged in the IM-Endpoints backlog record with daily-at-minimum status updates required until the notification is filed or the clock expires. EU AI Act Art. 50 transparency failure remediation: when a disclosure suppression or failure is identified (ML-Endpoints detection or ST-Endpoints test failure), the affected customer-facing AI endpoint must be remediated (disclosure restored and confirmed by ST test) within a documented SLA; if the suppression affected customers at scale, regulatory notification assessment is required; named owner Privacy/Legal plus product deployer-duty owner. EU AI Act Art. 73: serious-incident reporting timeline per the implementing act for Annex III high-risk endpoint systems; named owner Privacy/Legal plus executive sponsor; escalation is immediate on any Annex III-classified endpoint archetype incident. HIPAA: 60-day discovery-to-notification ceiling for covered entities and business associates; flag any AI/HAI endpoint incident involving PHI immediately; named owner Privacy/Legal. PCI-DSS endpoint breach notification, COPPA (children-facing endpoint incidents), FERPA (educational endpoint incidents), and sector mobile-banking obligations carry named owners per the organization's compliance program. Every Critical or blocker incident receives a post-incident review within 14 days of containment covering what happened (root cause, initiation path, controls that failed or were absent), what caught it (which ML-Endpoints detection, IM source, or external report surfaced it first; was this the expected detection path or a gap), what did not catch it (controls that should have detected or prevented this but did not), and update outputs to SA-Endpoints (pattern-update request if an architectural gap was exploited), SR-Endpoints (requirements-pack update if a missing or vague requirement was exploited), EG-Endpoints (training-content update if the incident indicates a literacy gap), and ML-Endpoints (detection-update request, new detection, tuned query, or evidence that an existing detection can be sharpened). Post-incident review outputs are tracked as IM issues of type "improvement" and age against the same process-metric cadence as other issues.

Outcome Metrics (L1).

Success Criteria.

• Single AI/HAI endpoint issue backlog established with standardized metadata; AI-endpoint-specific severity rubric published.
• Seven AI-specific endpoint incident playbook entries published (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper) with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets; each exercised in at least one tabletop in the last 12 months.
• Regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA (60d), PCI-DSS endpoint breach, COPPA, FERPA, and sector-specific obligations; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints; every Critical/blocker incident produces a review within 14 days with named update outputs per downstream practice.
• Program-sponsor dashboard refreshed monthly showing backlog aging, SLA adherence, and post-incident learning outputs.

Maturity Level 2

Objective: Calibrate incident response depth per SM-Endpoints L2 risk tier; operate dedicated 24/7 on-call coverage and pre-staged escalation for Critical-tier archetypes; auto-flow post-incident review outputs to SA/SR/EG/ML practice backlogs; activate cross-domain coordination when an Endpoints-domain incident implicates Software, Data, or Processes.

Activities.

A) Tier-calibrated incident playbook and on-call. Extend L1 playbook entries with tier-specific activation criteria and on-call coverage. Critical tier: full IM activation, CISO or delegate plus Privacy/Legal plus endpoint-security deployer-duty owner plus executive sponsor notification plus CTO and Communications routing; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named AI/HAI endpoint incident responder in each on-call rotation; pre-staged communication templates (internal, customer-facing, regulatory) loaded and reviewed quarterly. High tier: scoped response team, endpoint-security lead plus Privacy/Legal if regulated data involved plus deployer-duty owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with after-hours escalation path defined. Medium tier: standard response; ≤1 business day acknowledgement; queue-based triage. Low tier: tracked in queue with aggregated weekly handling. Critical-tier on-call rotation is documented per week with named individuals, coverage-handoff protocol, and an on-call briefing that includes the current Critical-tier archetype list, active detection set, and known compensating controls or gaps for each archetype (the active SaaS-AI feature inventory, the current edge-device tamper-detection coverage, and the chatbot rate-limit configuration baseline).

B) Post-incident review auto-flow integration. Wire IM-Endpoints post-incident review outputs to downstream practice backlogs via a defined integration. SA-Endpoints pattern-update requests auto-create architecture-backlog tickets with the IM-Endpoints incident reference linked. SR-Endpoints requirements-pack update requests auto-create pack-backlog tickets with the requirements-pack version and failing requirement row linked. EG-Endpoints training-content update requests auto-create training-backlog tickets with the affected population segment and incident summary linked. ML-Endpoints detection-update requests auto-create detection-registry update tickets with the detection name, current query, and proposed change linked. SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days; accepted updates are treated as High-severity issues in the receiving practice's backlog. The program sponsor reviews post-incident review quality quarterly, are update outputs substantive (concrete change to a pattern, pack, curriculum, or detection) or nominal (a note saying "consider reviewing")?

C) Cross-domain coordination protocol. Publish a cross-domain coordination protocol that activates when an Endpoints-domain AI/HAI incident implicates another domain. Endpoints → Software: a managed-endpoint AI assistant data-exfiltration incident reveals that regulated data was transmitted to a Software-domain LLM-backend service; activates Software-domain EH and IM alongside Endpoints-domain containment with a named Software-domain IM contact on file. Endpoints → Data: a SaaS-AI feature enabled without intake approval processed data that is classified as a Data-domain training corpus or prompt/completion log corpus; activates Data-domain EH and IM alongside the Endpoints-domain SaaS-AI silent-enablement play with a named Data-domain IM contact on file. Endpoints → Processes: a customer-facing chatbot output-corruption incident (multi-modal injection or jailbreak-at-scale producing harmful outputs) affected a customer-service workflow that routes outputs to a business-process decision; activates the Processes-domain business-continuity coordinator alongside the Endpoints-domain chatbot abuse play with a named Processes-domain IM contact on file. Cross-domain incident activations share a single status board, a single IC from the primary impacted domain, coordinated remediation tracking, and a joint post-incident review spanning all affected domains. Tier-movement in the SM-Endpoints inventory auto-triggers IM-Endpoints configuration updates: a Medium → Critical re-tier updates on-call path, playbook variant, and SLA targets within 14 days.

Outcome Metrics (L2).

Success Criteria.

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation including a current Critical-tier archetype briefing.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML-Endpoints backlogs; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents; named cross-domain contacts for Software, Data, and Processes domains verified quarterly.
• Tier-movement in the SM-Endpoints inventory auto-triggers IM-Endpoints configuration updates within 14 days for Critical re-tiers.

Maturity Level 3

Objective: Contribute endpoint incident patterns and playbook templates to sector ISACs, CSA Endpoint AI Safety Initiative, OWASP MASVS, and MITRE ATLAS; execute pre-authorized automated containment for defined low-severity high-confidence detections; benchmark MTTR against industry peers and link deltas to investment proposals.

Activities.

A) Industry-coordinated endpoint incident sharing and contribution. Participate in sector-ISAC AI endpoint incident-sharing programs (FS-ISAC AI working group, mobile-banking AI endpoint incidents; H-ISAC, patient-facing chatbot incidents; IT-ISAC, managed-endpoint AI incidents). Consume ISAC AI endpoint incident feeds and integrate relevant advisories into the IM-Endpoints external-advisory source. Contribute anonymized endpoint incident classification (incident type, ATLAS tactic tag, HAI-TTP tag, archetype, containment play used, MTTR achieved) on a per-incident-class basis; target ≥4 ISAC contributions per year. Contribute to AI endpoint incident standards: CSA Endpoint AI Safety Initiative (AI endpoint severity-anchor definitions, playbook template schemas for the seven endpoint incident classes, SaaS-AI shadow-enablement response templates); OWASP MASVS (mobile AI app incident response patterns, model-integrity failure response, on-device data-breach response, verification requirements for mobile AI app incident-response capability); OpenSSF AI (runbook schema for pre-authorized endpoint containment actions). Contribute to MITRE ATLAS endpoint-technique documentation, submit endpoint-derived technique observations or mitigation entries for endpoint-relevant tactics; target ≥1 ATLAS contribution per year for Endpoints-primary tactics.

B) Pre-authorized automated runbook decisioning. Define and publish a pre-authorization policy for automated containment actions, the set of actions that may execute without human approval when a detection fires at a defined confidence threshold. Pre-authorized actions include extension force-remove for a Low-tier or Medium-tier endpoint when an unsanctioned-browser-extension detection fires above 95% confidence (extension ID definitively not in allowlist, data-access permissions confirmed); SaaS-AI feature disable for a shadow-AI-in-SaaS detection on a non-Critical-tier SaaS feature (feature enablement event with no intake record, feature ID definitively not in approved list); edge-device remote-disable for a tamper-detection event on a non-Critical-tier edge device when a physical-tamper event fires above 99% confidence; and rate-limit emergency-tighten for a customer-facing chatbot when a chatbot-abuse-pattern-at-scale detection fires above 90% confidence (volume and pattern both exceeded). Pre-authorized actions for Critical-tier archetypes require human confirmation within 15 minutes; the action fires after that window if no confirmation arrives (timer-based fallback) with executive notification at fire time. All pre-authorized actions produce a full audit-log entry in the IM-Endpoints backlog, a human-review ticket auto-created at execution, and notification to the archetype's deployer-duty owner. The pre-authorization policy is reviewed quarterly by Privacy/Legal and the executive sponsor; any automated action producing an unexpected outcome triggers an out-of-cycle review.

C) MTTR benchmarking. Establish MTTR benchmarks from ISAC AI endpoint incident data exchanges, OWASP MASVS practitioner community data on mobile AI app incident response times, CSA Endpoint AI Safety Initiative observational data, and peer roundtables (CISO and AI-endpoint practitioner communities). Publish a quarterly MTTR benchmark brief to the program sponsor: MTTR per incident class vs. benchmark (regulated-data egress, unsanctioned extension, SaaS-AI silent-enablement, chatbot abuse, multi-modal injection, mobile-AI integrity failure, edge-device tamper); MTTR per tier (Critical, High, Medium) vs. benchmark; delta trend (improving, stable, degrading); and an investment driver, where MTTR is above benchmark, root-cause mapped to a specific practice gap (missing detection, unclear playbook, on-call latency) with a budget-linked improvement proposal.

Outcome Metrics (L3).

Success Criteria.

• ≥4 ISAC AI endpoint incident contributions per year, ≥2 CSA / OWASP MASVS contributions per year, ≥1 ATLAS Endpoints-tactic contribution per year; all contributions anonymized, legally vetted, and maintained for external adoption.
• ≥3 pre-authorized automated containment actions live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution; pre-authorization policy reviewed quarterly with zero unauthorized executions.
• Quarterly MTTR benchmark brief published to sponsor; Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes; deltas above benchmark linked to specific practice gaps and investment proposals.

Common Pitfalls

Level 1. - "Single backlog" created but source practices continue filing into separate queues, ML-Endpoints alerts route to a DLP console queue nobody monitors, ST-Endpoints failures stay in the CI dashboard, vendor SaaS-AI advisories land in a shared email inbox; the backlog achieves only 40% coverage and the ≥95% target is never reached. - Severity rubric anchors are generic (probability × impact without AI-endpoint-specific axes), a chatbot EU AI Act Art. 50 disclosure suppression affecting thousands of customer sessions is triaged Low because the rubric does not capture regulatory-notification triggers; it should be Critical. - Playbook entries published but roles not pre-assigned, on the first live SaaS-AI silent-enablement incident, the team spends the first 45 minutes figuring out who has access to the SaaS admin console to disable the feature instead of disabling it. - Post-incident reviews completed but outputs filed in a shared document that no downstream practice owner reads, SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints do not update; the same chatbot jailbreak pattern recurs with the same output-filter gap six months later.

Level 2. - Critical-tier activation criteria are vague, a chatbot abuse campaign at scale that qualifies for full-team plus executive activation stays in the standard queue until the product owner escalates on Monday; the ≤1-hour MTTA SLA is already missed by the time the right people engage. - Post-incident review auto-flow integration wired but downstream practice backlogs never treat the auto-created tickets as actionable, the SR-Endpoints team closes the ticket as "acknowledged" without updating the requirements pack; the same unsanctioned-extension gap recurs. - Cross-domain coordination protocol exists on paper but no IC is pre-designated, the first cross-domain incident where a managed-endpoint AI assistant data-exfiltration reaches a Software-domain LLM backend produces ownership confusion; Endpoints-domain IM and Software-domain IM both wait for the other. - 24/7 on-call coverage implemented but the on-call briefing is stale, the rotation shift includes a Critical-tier archetype list that was accurate 90 days ago; a new Critical-tier customer-facing chatbot added last sprint is not in the briefing and on-call responders do not know the escalation path for it.

Level 3. - ISAC participation limited to consuming feeds, contributions are absent, the organization is labeled a free-rider, influence over AI endpoint incident taxonomy standards diminishes. - Pre-authorized automated containment fires on a Critical-tier archetype because the confidence threshold was set too loosely, a false positive executes a rate-limit tighten on a production customer-facing chatbot during peak traffic; the pre-authorization policy had no Critical-tier exception check. - MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI endpoint portfolio scale, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch. - Automated containment produces audit records that are technically complete but lack the narrative context needed for a post-incident root-cause review, humans reviewing automated extension-force-remove logs cannot reconstruct what the detection saw and why the confidence threshold triggered.

Practice Maturity Questions

Level 1. 1. Is a single AI/HAI endpoint issue backlog operating with standardized metadata (source, affected archetype linked to SM-Endpoints inventory, severity rubric anchored to AI-endpoint-specific axes, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA-Endpoints, SR-Endpoints, DR-Endpoints, IR-Endpoints, ST-Endpoints, ML-Endpoints, external)? Evidence: backlog audit cross-referenced against per-practice source queues for the last 90 days. 2. Is the AI-specific endpoint incident playbook published with seven named incident classes (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months? Evidence: published playbook; tabletop exercise records covering all seven classes. 3. Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA (60d), PCI-DSS endpoint breach, COPPA, FERPA, and sector-specific obligations with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints? Evidence: SLA tracker export; post-incident review records with downstream-practice update tickets.

Level 2. 1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier archetype briefing, and tier-movement in the SM-Endpoints inventory automatically triggering IM-Endpoints configuration updates within 14 days for Critical re-tiers? Evidence: IM-Endpoints telemetry showing MTTA/MTTC distributions; on-call rotation registry with briefing; auto-update log for tier-movement events. 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML-Endpoints practice backlogs with ≥90% of downstream practice owners responding within 14 days, and is sponsor review of output quality occurring quarterly to distinguish substantive changes from nominal acknowledgements? Evidence: integration telemetry; downstream backlog aging report; quarterly sponsor review notes. 3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents with named cross-domain contacts for Software, Data, and Processes domains verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains? Evidence: published protocol; cross-domain contact registry with quarterly verification log; joint post-incident review records.

Level 3. 1. Does the program contribute ≥4 anonymized AI endpoint incident-classification entries per year to sector ISACs, ≥2 contributions per year to CSA Endpoint AI Safety Initiative or OWASP MASVS, and ≥1 contribution per year to MITRE ATLAS Endpoints-tactic documentation with all contributions maintained current, legally vetted, and tracked for external adoption? Evidence: contribution log with submission dates and upstream adoption references. 2. Are ≥3 pre-authorized automated containment actions live (extension force-remove, SaaS-AI feature disable, edge-device remote-disable, or chatbot rate-limit tighten classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with quarterly policy review and zero unauthorized executions? Evidence: pre-authorization policy; automation execution log with audit records and human-review tickets; quarterly review minutes. 3. Is a quarterly MTTR benchmark brief published to the sponsor comparing MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals? Evidence: quarterly benchmark briefs for the last 12 months with benchmark sources and investment-proposal references.

25. Monitoring & Logging (ML)

Practice Overview

Objective: Establish the logging baseline per AI/HAI endpoint archetype, operate a small high-signal detection set targeted at the top threats from TA-Endpoints, and produce the evidence trail that proves EU AI Act Art. 12 and Art. 50 deployer duties, GDPR Art. 30 processor obligations, and ISO/IEC 42001 AIMS requirements on demand inside a published SLA.

Description: ML-Endpoints captures the signals produced by every AI/HAI-enabled endpoint and user-facing AI interface the organization deploys or offers, AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, AI-augmented productivity (SaaS-AI on endpoint), mobile AI app, and edge AI device. For each archetype it specifies the exact events to capture (session events, DLP-decision events, tool-call events, admin-audit events, identity events, and archetype-specific integrity and safety events), the retention window required to satisfy the longest applicable regulation (EU AI Act Art. 12 high-risk-system logs ≥6 months; GDPR Art. 30 records-of-processing per data-class and processing purpose; HIPAA PHI ≥6 years; COPPA, FERPA, sector mobile-banking where applicable), and the export path that supports auditor and regulatory review within a published SLA. On top of the logging baseline it operates a bounded, purposeful detection set, each detection tied to a TA-Endpoints archetype threat, with a named owner, a defined query, an SLA, and an active tuning record. The full corpus is the primary evidence artifact for PC-Endpoints' priority compliance map: EU AI Act Art. 50 transparency-failure audit trail, GDPR Art. 30 records of processing for customer-facing AI, and ISO/IEC 42001 AIMS operational evidence.

Context: Logging AI/HAI endpoints is not the same as logging classic web applications. A DLP-decision event on a managed endpoint must carry the data class detected, the DLP rule applied, the action taken (block / allow / redact), and the AI tool context, not only an HTTP status code. A chatbot interaction event must carry the disclosure-shown flag, the AI step, the escalation-trigger-evaluated flag, and the abuse-detection outcome, not only a message payload. An edge AI device event must carry the boot-attestation result, the firmware version, and the uplink timestamp, not only a connection log. A SaaS-AI admin-audit event must capture the specific AI feature that was enabled or disabled, the scope change, and the approver identity, not only a generic SaaS audit entry. None of this exists by default in standard SIEM tooling unless the archetype's event schema has been explicitly defined and instrumented. ML-Endpoints makes that schema explicit, per archetype, from day one, so the organization is not reconstructing an evidence trail from incomplete telemetry the first time a regulator or incident demands it. ML-Endpoints is also the upstream feed for IM-Endpoints: detections route directly to the unified backlog, and post-incident review outputs return to ML as detection-update requests.

Maturity Level 1

Objective: Establish the per-archetype logging baseline, operate a small high-signal detection set targeting the top TA-Endpoints threats and HAI TTPs, and produce an on-demand evidence trail satisfying EU AI Act Art. 12 and Art. 50, GDPR Art. 30, and ISO/IEC 42001 AIMS within a published SLA.

Activities.

A) Establish the per-archetype logging baseline. Define and instrument the minimum event schema for each AI/HAI endpoint archetype in the SM-Endpoints inventory. Every event record carries an event-id / correlation-id, principal (user or device identity), timestamp, archetype tag, endpoint-id or device-id linked to the SM-Endpoints inventory, and the archetype-specific fields below. AI assistant / copilot on managed endpoint: session event (principal, endpoint-id, AI provider, model name and version, session-id, session-start and session-end timestamps, data-class of session context as assessed by DLP), paste-block / paste-allow DLP-decision event (data class detected, DLP rule applied, action taken, AI tool context, session-id), tool-call event for tool-using assistants (tool name, arguments or argument hash for sensitive parameters, return value or hash, success/fail), admin-audit event (allowlist change, configuration change, model-version change, session-policy change). Browser-based AI tool: extension-install / extension-uninstall event (extension name, extension ID, install source, principal, endpoint-id), extension-permission-grant event, DLP-decision event with browser context (domain, page type), backend-SSO event for sign-ins to AI tools via browser. Chatbot / conversational UI: customer-interaction event (session-id, AI step including intent classification / retrieval / generation / output-filter result, disclosure-shown flag with disclosure-template-version, escalation-trigger-evaluated flag, escalation-triggered flag, PII redaction rule applied; raw customer-message content is not logged in clear-text if it contains regulated data), output-filter event, abuse-detection event (pattern matched, action taken). Multi-modal AI interface: input event (modality, content hash not raw content for regulated data, validation-decision result, validator version), output safety-filter event, cross-modal consistency event. AI-augmented productivity (SaaS-AI on endpoint): admin-audit event for AI feature-enablement change (feature name, previous state, new state, scope change, approver identity, change method, console vs. API vs. IaC), per-feature usage event (feature name, principal, data-scope accessed, session-id), DLP-decision event for SaaS-AI data flows. Mobile AI app: app-launch event (app version, local-model version, device-id), permission-grant event (camera / microphone / location / storage), local-model integrity event (integrity check result, model hash verified, reference hash source), on-device action event. Edge AI device: boot-attestation event (device-id, firmware version, attestation result, TPM/HSM attestation token reference, sealed PCR values hash), physical-tamper event, uplink event (data class, volume, destination endpoint), remote-disable event. Admin-audit events across archetypes capture MDM policy changes, browser policy changes, SaaS-admin AI-feature changes, vendor-configuration changes (no-train flag status change), and rate-limit / abuse-detection configuration changes. Identity events capture SSO sign-ins to AI provider management consoles, AI assistant admin consoles, SaaS AI admin panels, and edge device management consoles, plus conditional-access decisions for AI surface access. Retention meets or exceeds the longest applicable requirement across active regulations (EU AI Act Art. 12 ≥6 months; GDPR Art. 30 per data-class; HIPAA PHI ≥6 years; sector overlays for COPPA, FERPA, mobile banking); where multiple windows apply, the longest governs. Export path (JSON or structured CSV) tested at least annually; on-demand pull SLA ≤24 hours. Admin-audit and deployer-duty evidence tiers use write-once or append-only storage with access-control separation between endpoint management teams and log-store administrators. PII scrubbing applied per SR-Endpoints data-boundary requirements before logs reach long-term storage.

B) Operate a small high-signal detection set. L1 target ≤12 detections, each tied to a TA-Endpoints archetype threat and to at least one HAI TTP tag (EA / AGH / TM / RA) or ATLAS tactic, each with a named owner, detection query, SLA (time-to-IM-Endpoints-ticket), and last-tuned date. Core detections: regulated-data paste-attempt blocked at high volume (EA, DLP block events for regulated-data paste into AI tool prompt fields exceed a per-user or per-endpoint threshold within a rolling window; routes to IM-Endpoints and EG-Endpoints training referral); customer-data egress via AI assistant (ATLAS TA0013 Exfiltration / AGH, DLP allow event where the data class is regulated customer data and the destination is an AI tool endpoint; any single allow event at this classification routes immediately to IM-Endpoints as a High-severity finding); unsanctioned browser extension installed (EA, extension-install event where the extension ID is not in the SM-Endpoints browser-extension allowlist); SaaS-AI feature enabled tenant-wide without intake (EA, SaaS-admin audit event recording a new AI feature enablement with no matching SM-Endpoints intake approval); mobile-app local-model integrity failure (any single failure routes to IM-Endpoints for MDM force-update evaluation); edge-device tamper / attestation failure (boot-attestation event with result fail or physical-tamper event with sensor triggered; routes immediately to IM-Endpoints for remote-disable evaluation); chatbot EU AI Act Art. 50 disclosure suppression / failure (customer-interaction event with disclosure-shown flag false where disclosure is required); customer-facing chatbot abuse-pattern at scale (ATLAS TA0008 Defense Evasion / AGH, abuse-detection events of type jailbreak-attempt or prompt-injection-attempt at volume above threshold); cross-tenant data exposure via SaaS-AI feature (TM, DLP-decision event for SaaS-AI data flows where the data scope accessed includes a tenant or organizational-unit boundary not declared in the feature's intake record). Each detection routes to the IM-Endpoints backlog on fire; median detection-to-ticket time target ≤1 hour for Critical-tier archetypes; false-positive rate tracked per detection with monthly tuning review.

C) Produce and drill the deployer-duty evidence trail. ML-Endpoints is the primary evidence source for PC-Endpoints' priority compliance map. Wire the log store to the compliance requirements. EU AI Act Art. 12 (high-risk system logging for deployer duties): for every endpoint archetype assessed as Annex III high-risk or carrying a customer-facing decision-affecting output, confirm that interaction events, output-filter events, and admin-audit events are captured and retained at the required window; produce a deployer-duty evidence view for each such archetype. EU AI Act Art. 50 (transparency / disclosure obligations): for every customer-facing chatbot and multi-modal AI interface, the disclosure-shown flag and disclosure-template-version in the customer-interaction log constitute the Art. 50 audit trail; retention confirms the trail is available for the required window; export path tested annually. GDPR Art. 30 (records of processing): for every endpoint archetype processing personal data, the DLP-decision events, session events, and admin-audit events with principal identity and data-class tag constitute the records-of-processing operational entries; link the log-store retention policy to the Art. 30 record for each archetype. ISO/IEC 42001 AIMS (operational evidence): admin-audit events for AI-feature enablement changes, DLP-rule changes, rate-limit configuration changes, and integrity-check results constitute the AIMS operational records; identify gaps and open IM-Endpoints findings for any archetype not yet emitting these events. Sector overlays: COPPA for children-facing endpoints (interaction logs must not contain PII for minors in clear-text; age-gate decision events), FERPA for educational endpoints (student-data access events), sector mobile-banking regulations (mobile AI app transaction events with compliance flag). Quarterly deployer-duty drill: pull the deployer-duty evidence package for one randomly selected production endpoint archetype within the published SLA (≤24 hours from request to assembled package); record drill results; gaps route to IM-Endpoints.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype logging baseline published and instrumented for ≥90% of production AI/HAI endpoint archetypes; PII scrubbing applied before long-term storage.
• ≤12-detection high-signal set live, each with owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, and monthly tuning record; false-positive rate tracked per detection.
• Retention meets the longest applicable regulatory window for every production endpoint archetype; export SLA ≤24 hours tested at least annually.
• EU AI Act Art. 12 and Art. 50, GDPR Art. 30, and ISO/IEC 42001 AIMS evidence-trail wiring documented; quarterly deployer-duty drill executed inside the ≤24-hour SLA; sector overlays (COPPA, FERPA, sector mobile-banking) applied where applicable.

Maturity Level 2

Objective: Calibrate logging depth and detection set to the SM-Endpoints L2 risk-tier rubric; integrate ML-Endpoints feeds into the SIEM for cross-archetype correlation; operate a quarterly detection-tuning loop fed by IM-Endpoints post-incident reviews and ST-Endpoints findings; establish anomaly-detection baselines for Critical and High-tier archetypes.

Activities.

A) Tier-calibrated logging depth. Apply the SM-Endpoints L2 tier-treatment matrix to logging configuration. Critical: full interaction-event and DLP-decision log corpora (not hashes) retained for the longest regulatory window; full admin-audit events at maximum fidelity; all detections tuned to the archetype; log store partitioned from other tier logs; anomaly detection baselines established. High: full interaction and DLP-decision events retained; standard admin-audit; core detections active; anomaly detection baselines established. Medium: interaction-event hashes retained for the regulatory window; standard admin-audit; shadow-AI emergence and baseline detections active. Low: baseline logging schema only; shadow-AI emergence detection only. For every Critical-tier endpoint archetype the ML-Endpoints log store is the primary source for PC-Endpoints' compliance evidence bundle, completing inside the PC-Endpoints L2 staleness threshold (≤30 days).

B) SIEM integration and cross-archetype correlation. Ingest all tier-appropriate ML-Endpoints log feeds into the SIEM. Author and maintain at least three cross-archetype correlation rules: multi-archetype data-exfiltration chain (a regulated-data DLP-allow event on an AI assistant followed by a matching data-class access event on a SaaS-AI feature from the same principal within the same session window, fires a correlated exfiltration-chain detection); browser-extension to SaaS-AI lateral move (an unsanctioned-extension-install detection on a browser-based AI tool correlates to a SaaS-AI feature-enablement admin-audit event from the same principal within 24 hours, signals potential insider shadow-AI expansion); chatbot abuse escalation chain (a chatbot abuse-pattern detection correlates to an unusual SSO sign-in to the AI provider management console from the same principal's device within the same time window, signals attacker escalation from user-facing to admin surface). Cross-archetype correlation alerts route to IM-Endpoints at the tier of the highest-tier archetype involved with links to component-archetype findings to preserve triage context.

C) Detection tuning loop and anomaly baselines. Operate a quarterly detection review cycle. IM-Endpoints post-incident reviews that touch a logging or detection gap generate detection-update requests (new detection, tuned query, or retired false-positive rule). ST-Endpoints test findings (disclosure-suppression tests not caught by current detection, DLP bypass tests, chatbot abuse-pattern tests not in the detection corpus, edge attestation bypass tests) generate detection-gap findings routed to ML-Endpoints. External advisory updates are assessed quarterly: MITRE ATLAS endpoint-technique updates, OWASP MASVS new controls, browser-extension store flags for AI extensions with flagged behavior, mobile app store flags for AI apps with data-exfiltration findings, and edge-device CVEs with AI system impact; each applicable update either adds a candidate detection or updates an existing detection's query. Monthly anomaly-baseline refresh for Critical and High-tier endpoint archetypes: normal behavioral baseline (DLP-decision volume, session patterns, extension-install rate, SaaS-AI feature usage patterns, mobile-app integrity check results, edge attestation cadence) refreshed from the previous 30-day window; anomaly threshold auto-tunes to maintain target false-positive rate. Each detection has a last-tuned date and a false-positive rate; detections that have not fired a true positive in 90 days or that exceed a 20% false-positive rate are reviewed for retirement at the quarterly cycle. Retention-tier calibration reconciles with SM-Endpoints inventory tier changes within 14 days (Critical re-tier) or 30 days (other tiers).

Outcome Metrics (L2).

Success Criteria.

• Tier-calibrated logging depth applied to 100% of SM-Endpoints inventory with current tier assignments; Critical-tier full corpus retention confirmed; calibration auto-updated on re-tier within 14 days for Critical re-tiers.
• SIEM integration live with ≥3 cross-archetype correlation rules active.
• Quarterly detection tuning loop operating from IM-Endpoints and ST-Endpoints feedback with ≥1 net change per cycle.
• ≥90% of Critical/High-tier endpoint archetypes with anomaly-detection baselines refreshed monthly; FP rate tracked and trending down.
• ML-Endpoints logging-baseline validation element fresh (≤30 days) for all Critical-tier archetypes in PC-Endpoints compliance evidence bundles.

Maturity Level 3

Objective: Express detections as code deployed through CI/CD; apply ML-driven anomaly detection on endpoint-AI behavioral corpora; contribute anonymized detection signatures and telemetry schemas to CSA Endpoint AI Safety Initiative, OpenTelemetry AI, OWASP MASVS, and sector ISACs.

Activities.

A) Detection-as-code. Every detection in the set is a version-controlled, tested artifact in source control with detection query plus metadata (owner, SLA, ATLAS-tactic tag, HAI-TTP tag, false-positive threshold, last-test-result). A detection CI/CD pipeline triggers a test suite (unit tests over synthetic endpoint-AI event log data, integration tests against a log replay environment) before production deployment. Detection deployment runs through the same change-management pipeline as AI/HAI endpoint configuration; detection changes are reviewed, not applied ad hoc in the SIEM console. Detection coverage is automatically checked on SM-Endpoints inventory change events: when a new endpoint archetype is registered or an archetype is re-tiered to Critical, the automation verifies the required detection set is active for that archetype and opens a gap finding within 24 hours if not.

B) ML-driven anomaly detection on endpoint-AI behavioral corpora. Apply unsupervised and semi-supervised anomaly models to the endpoint-AI behavioral corpus for Critical and High-tier archetypes. DLP-decision sequence anomaly identifies sessions whose DLP-decision sequence (block frequency, data-class distribution, AI tool context pattern) is a statistical outlier from normal user sessions, attacker data-staging signatures, pre-exfiltration paste patterns, policy-bypass probe sequences. Extension-install behavior anomaly identifies extension-install patterns (install frequency, extension permission profile, install timing relative to DLP events) outside the baseline distribution for the endpoint cohort, signals potential insider or compromised-account extension deployment. SaaS-AI feature-usage anomaly identifies feature-usage events whose data-scope-access distribution shifts from baseline on a rolling window, potential cross-tenant access attempt or unusual bulk-data access via a SaaS-AI feature. Edge-device attestation cadence anomaly identifies edge devices whose attestation event cadence, PCR-value-change pattern, or uplink-volume distribution deviates from the device cohort baseline, signals potential firmware tampering or replay-attack preparation. Mobile-app integrity failure cluster identifies clusters of local-model integrity failures across a device cohort within a time window, signals a coordinated model-swap attempt or a compromised model distribution channel. Anomaly model outputs feed the same detection-to-IM-Endpoints-ticket pipeline as rule-based detections; anomaly severity is tagged to the archetype's tier. Anomaly models are retrained monthly; retraining produces a new version in the ML-Endpoints model registry with lineage tracking equivalent to production AI/HAI software. Retraining excludes attacker-session logs from past incidents to avoid baseline poisoning.

C) Contribute detection signatures and telemetry schemas to industry. Contribute semantic event schemas for AI/HAI endpoint telemetry (DLP-decision events for AI prompt contexts, SaaS-AI admin-audit events, edge-device attestation events, mobile-AI integrity events) to the CSA Endpoint AI Safety Initiative and to the OpenTelemetry AI workgroup in OTel-compatible format; target ≥2 schema contributions per year. Contribute detection-pattern examples and verification criteria for mobile AI app security to OWASP MASVS (local-model integrity verification patterns, on-device AI data-boundary detection controls, secure enclave usage verification for AI operations); target ≥1 MASVS contribution per cycle per year. For each detection that corresponds to an ATLAS tactic / technique, propose or validate an AML.M00xx mitigation entry (detection-based mitigation type) covering Endpoints-primary tactics. Share anonymized, generalized detection signatures with sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), mobile-banking AI app integrity detection patterns for FS-ISAC, patient-facing chatbot abuse-detection patterns for H-ISAC, managed-endpoint AI signatures for IT-ISAC; target ≥12 signatures per year, implementable by partner organizations without significant adaptation. Target ≥2 telemetry-standard contributions per year and ≥12 ISAC detection signatures per year; all contributions anonymized, legally vetted, and maintained, not point-in-time submissions.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of detections expressed as version-controlled, CI/CD-deployed artifacts; detection coverage auto-verified for 100% of new or re-tiered SM-Endpoints inventory entries within 24 hours.
• ≥90% of Critical/High-tier endpoint archetypes running ML-driven anomaly detection on endpoint-AI behavioral corpora with monthly retraining and lineage tracking.
• ≥2 telemetry-standard contributions per year to CSA Endpoint AI Safety Initiative or OpenTelemetry AI workgroup; ≥12 anonymized detection signatures per year to sector ISACs; OWASP MASVS contributions for mobile AI app integrity detection patterns submitted and maintained; ≥2 ATLAS AML.M00xx mitigation entries proposed or validated.

Common Pitfalls

Level 1. - Logging baseline defined at the archetype level but actual production archetypes never audited against it, gaps accumulate inside the SM-Endpoints inventory without appearing in any backlog; the chatbot never emits a disclosure-shown flag event because instrumentation was never implemented. - DLP-decision events logged at the endpoint but not correlated with session-id or AI-tool context, the log shows "block: regulated data" but no analyst can determine which AI tool was involved, which user session it was, or whether the data was pasted once or across a 30-minute probing session. - EU AI Act Art. 50 disclosure-shown flag logged in the chatbot interaction event but the flag is always true because the code sets it to true before checking whether the disclosure was actually rendered, a rendering bug suppresses the disclosure for 20% of sessions; the ML-Endpoints log shows 100% compliance; the ST-Endpoints test battery would have caught it but was never wired. - SaaS-AI admin-audit events captured for the data catalog UI but not from the SaaS provider API, a tenant-admin enables an AI feature via the provider's mobile admin app; the event is not captured by the log pipeline and shadow-AI-in-SaaS goes undetected.

Level 2. - Tier-calibrated logging configured at deployment but not maintained, when an endpoint archetype is re-tiered from Medium to Critical, logging depth is not updated and full corpora are absent for the archetype when the first Critical-tier incident fires. - SIEM correlation rules built once and never validated, a correlation rule that has not fired in 90 days may be broken (log format changed, field name renamed after a SaaS-provider update) rather than evidence that no correlatable events occurred. - Anomaly baselines established at onboarding and never refreshed, seasonal usage patterns (holiday chatbot traffic, quarterly SaaS-AI feature rollout cycles) make the baseline stale; FP rates spike during peak periods and analysts stop trusting the anomaly feed. - Detection tuning loop exists on paper but IM-Endpoints and ST-Endpoints feedback never actually enters the review cycle, the same disclosure-suppression detection false-positive remains in the set for 18 months because the quarterly process has no dedicated owner.

Level 3. - Detection-as-code pipeline deployed but detection tests use synthetic log data that does not include SaaS-AI admin-audit event formats, tests pass in CI; detections fail silently in production when the SaaS provider updates its audit-log schema. - Anomaly models trained on the full endpoint-AI behavioral corpus including attacker-session logs from past incidents, poisoned baseline; the anomaly model learns to treat past DLP-bypass patterns as normal. - Contributed telemetry schemas published as point-in-time artifacts and then diverge from internal practice, external adopters build against the v1.0 schema while the org operates v1.3 internally; trust erodes and the CSA contribution is retracted. - ISAC detection signatures generalized to the point of uselessness, partner organizations cannot implement them without reconstructing the SaaS-AI or edge-device context removed for anonymization.

Practice Maturity Questions

Level 1. 1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each 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), and has compliance of each production archetype been measured against it within the last quarter with ≥90% meeting the baseline? Evidence: published baseline; logging configuration audit cross-referenced against SM-Endpoints inventory with gap list on IM-Endpoints backlog. 2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, and last-tuned date, covering regulated-data paste-attempt, customer-data egress via AI assistant, unsanctioned browser extension, SaaS-AI shadow-enablement, mobile-app local-model integrity failure, edge-device tamper / attestation failure, chatbot Art. 50 disclosure suppression, chatbot abuse-pattern at scale, and cross-tenant SaaS-AI data exposure, with false-positive rates tracked per detection and monthly tuning reviews occurring? Evidence: detection registry export; monthly tuning-review records; FP-rate trend per detection. 3. Has the evidence trail for EU AI Act Art. 12 and Art. 50, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Endpoints log store, including sector overlays (COPPA, FERPA, sector mobile-banking) where applicable, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production endpoint archetype can be assembled within the ≤24-hour SLA? Evidence: documented wiring of log store to compliance requirements; quarterly drill records for the last 12 months with assembly times.

Level 2. 1. Is tier-calibrated logging depth applied per the SM-Endpoints L2 tier-treatment matrix, Critical-tier archetypes retaining full interaction-event and DLP-decision log corpora at the longest regulatory window, Low-tier archetypes receiving baseline only, and is this calibration automatically updated when an archetype is re-tiered (Critical re-tier within 14 days; other tiers within 30 days)? Evidence: log-store retention audit × SM-Endpoints inventory tier assignments; re-tier auto-update log. 2. Is the SIEM ingesting ML-Endpoints log feeds with ≥3 cross-archetype correlation rules active (covering multi-archetype data-exfiltration chain, browser-extension to SaaS-AI lateral move, and chatbot abuse escalation chain), and is a quarterly detection tuning cycle operating from IM-Endpoints post-incident and ST-Endpoints finding inputs with external advisory updates from ATLAS endpoint techniques, OWASP MASVS, app-store flags, and edge-device CVEs reviewed quarterly? Evidence: SIEM rule registry; correlation-alert sample; quarterly detection change log; external-advisory intake log. 3. Are ≥90% of Critical/High-tier endpoint archetypes running anomaly-detection baselines refreshed monthly with FP rates tracked and trending down, and is the ML-Endpoints logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier archetypes in PC-Endpoints compliance evidence bundles? Evidence: detection telemetry showing baseline-refresh cadence; FP-rate trend; PC-Endpoints compliance evidence bundle freshness report.

Level 3. 1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic endpoint-AI log data (including SaaS-AI admin-audit formats, edge-device attestation events, and mobile-AI integrity events), and is detection coverage auto-verified for 100% of new or re-tiered SM-Endpoints inventory entries within 24 hours of the inventory change event? Evidence: detection registry × source control; CI test results; automation telemetry for inventory-change events. 2. Are ≥90% of Critical/High-tier endpoint archetypes running ML-driven anomaly detection on endpoint-AI behavioral patterns (DLP-decision sequences, extension-install behavior, SaaS-AI feature-usage patterns, edge attestation cadence, mobile integrity failure clusters) with anomaly models retrained monthly on production log data (excluding attacker-session logs from past incidents), model versions tracked in the ML-Endpoints model registry, and anomaly alerts feeding the IM-Endpoints backlog through the same detection-to-ticket pipeline as rule-based detections? Evidence: anomaly model registry with monthly retraining records; lineage-tracking export; IM-Endpoints backlog showing anomaly-sourced tickets. 3. Has the program contributed ≥2 telemetry-standard artifacts per year to CSA Endpoint AI Safety Initiative or the OpenTelemetry AI workgroup, ≥12 anonymized detection signatures per year to sector ISACs, and OWASP MASVS contributions for mobile AI app integrity detection patterns, with ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries proposed or validated and all contributions maintained current with external adoption tracked? Evidence: contribution log with submission dates, upstream adoption references, and maintenance records.

Part IV, Maturity Assessment Workbook

26. How the assessment works

Scope. A single assessment covers all 12 practices in the Endpoints domain, with 3 questions per maturity level per practice, 108 questions total. The assessment measures the organization's ability to secure the AI/HAI-enabled endpoints and user-facing AI interfaces the program deploys, manages, or governs, across all seven canonical archetypes: AI assistants and copilots on managed endpoints, browser-based AI tools, chatbots and conversational UIs, multi-modal AI interfaces, AI-augmented productivity (SaaS-AI) features, mobile AI apps, and edge AI devices. The subject of every question is the endpoint AI surface itself, not the use of AI to perform endpoint security.

Cumulative levels. Maturity levels are cumulative. A practice cannot be at Level 2 unless it is at Level 1; it cannot be at Level 3 unless it is at Level 2. The team should score Level 1 questions before answering Level 2 questions for the same practice. This is not optional, the gate is by design and prevents the program from claiming downstream automation maturity (L3) on top of a missing inventory (L1).

Answers. Each question accepts one of three answers: Yes (fully implemented, evidence-backed, sustained over time, requires an artifact, telemetry pull, console screenshot, or process record the assessor has actually seen), Partial (partially implemented, or implemented but not sustained, or evidence is incomplete, counts as half credit), or No (not implemented, or implemented inconsistently to the point that no evidence supports it).

Evidence. Every "Yes" requires a citation in the Evidence box. "It is in the wiki" is not evidence. "Wiki page X dated Y, MDM compliance export from Intune dated Z, SaaS-admin AI-feature dashboard screenshot from M365 Admin Center dated W, LMS attestation export from HR system" is. For endpoint AI, evidence almost always lives in one of seven places: MDM/UEM console, browser-extension admin console, SaaS-admin AI-feature console, identity provider OAuth event log, EDR egress telemetry, mobile MDM, or edge device attestation service.

Honesty. The assessment is for the program, not for the assessor. A "No" honestly recorded is more useful than a "Yes" that does not survive auditor scrutiny, especially for EU AI Act Art. 50 disclosure obligations on own-built customer-facing chatbots and multi-modal interfaces, where overstating maturity creates direct regulatory exposure.

Cadence. The program runs the full assessment at least annually. The program runs a Level 1 self-check quarterly during the first year of operation, when shadow endpoint AI discovery is still seeding the inventory and the seven-archetype coverage is still consolidating.

Roles. The assessment is led by the AI/HAI Endpoint Assurance program lead (typically the endpoint security lead or AI security lead) working with the cross-functional working group. The Endpoints domain requires CISO and CIO co-sponsorship, the CIO owns the endpoint management substrate (MDM, EDR, browser, SaaS-admin, identity) on which all controls land, and the CISO owns the AI-specific risk posture. The working group should include Endpoint Management (MDM, EDR, UEM operators), IT (browser administration, SaaS administration, identity), Workplace Technology (productivity SaaS-AI feature governance), Privacy/Legal (Art. 50 disclosure UX, consent basis, sector overlays), Engineering and Product (own-built chatbot, mobile AI, edge AI surfaces), and HR (acceptable use). The assessor should be independent of day-to-day program operations, a peer assessor from another team or function works well; an external assessor works better. The program lead should not assess their own program.

Scope boundary. This assessment covers only Endpoints-domain practices. The same 12 practices applied to the Software, Data, Infrastructure, Vendors, and Processes domains are assessed in their own handbooks. The Endpoints domain governs the endpoint-layer surface regardless of build origin, own-built chatbots, mobile AI apps, and edge AI devices are first-party surfaces with direct deployer-duty obligations governed primarily here, while vendor AI tools consumed on endpoints (M365 Copilot, coding assistants, browser extensions, productivity SaaS-AI) are cross-referenced with the Vendors domain but the endpoint-layer controls (MDM, DLP, browser policy, SaaS-admin configuration, identity conditional access) are owned by this domain. The team must not conflate Endpoints-domain answers with answers about what a vendor's backend does, what the underlying network infrastructure provides, or how the data pipeline handles content after it leaves the endpoint.

27. Scoring methodology

Two scoring approaches are supported. Use the simplified scoring for self-assessments and quarterly check-ins. Use the precise scoring for formal audits and external benchmarking.

Simplified scoring (recommended for self-assessment)

For each practice:

Level 1 achieved (all 3 Level 1 questions = Yes): 1.0 point
Level 2 achieved (all 3 Level 2 questions = Yes, AND Level 1 achieved): +1.0 (total 2.0)
Level 3 achieved (all 3 Level 3 questions = Yes, AND Level 2 achieved): +1.0 (total 3.0)

A "Partial" answer counts as half toward the level, but the level is only achieved when all three questions are at full Yes. Partial credit shows up in the precise score. A practice with two Yes and one Partial at Level 1 has not achieved Level 1 in simplified scoring, even though it scores 0.83 in the precise calculation.

Precise scoring (recommended for formal audits)

For each practice, with Y = Yes (1.0), P = Partial (0.5), N = No (0):

L1_score = (sum of L1 answers) / 3
L2_score = (sum of L2 answers) / 3 × L1_score
L3_score = (sum of L3 answers) / 3 × L2_score

Practice Score = L1_score + L2_score + L3_score    (max 3.0)

The L2 and L3 multipliers enforce the cumulative rule, a practice cannot earn full L2 credit if L1 is incomplete, and a practice cannot earn any L3 credit at all if L2 is at zero. This matters especially for the Endpoints domain, where automation-heavy L3 work (signal-driven inventory, daily attestation, adaptive-policy pipelines) is meaningless without L1 inventory completeness and L2 tier calibration underneath.

Domain rollup.

Domain Maturity = (sum of all 12 Practice Scores) / 12    (max 3.0)

Maturity bands.

• 0.0 – 0.9, Ad-hoc. No AI/HAI Endpoint Assurance program in operational use; endpoint AI deploys without governance; shadow endpoint AI is invisible to the program; customer-facing chatbots ship without Art. 50 disclosure review.
• 1.0 – 1.9, Foundational. L1 in place across most practices; seven-archetype inventory exists; the three priority endpoint AI policies are published; shadow endpoint AI is being measured; some L2 progress on the risk-tier rubric.
• 2.0 – 2.9, Comprehensive. L2 calibrated by risk tier across most practices; per-tier scoreboard reported quarterly; Critical-tier customer-facing chatbots carry continuous compliance evidence bundles; some L3 contributions to CSA, OWASP MASVS, or OASIS.
• 3.0, Industry-Leading. L3 automation, benchmarking, and contribution sustained across all practices; inventory and tier auto-update from MDM/SaaS-admin/identity signals; daily attestation across Critical endpoints; the program is a net contributor to the endpoint-AI assurance ecosystem.

Worked example, precise scoring

Suppose the TA-Endpoints practice scores as follows:

L1_score = 2.5 / 3 = 0.833
L2_score = (1.5 / 3) × 0.833 = 0.500 × 0.833 = 0.417
L3_score = (0.0 / 3) × 0.417 = 0.0

TA Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: the practice is solidly in the Foundational band, with a partial L2 story. The seven archetype threat models exist and the per-intake snapshot is delivered, but the shadow-endpoint-AI threat view is incomplete (L1 Q3 Partial); external endpoint AI threat intel is being triaged but not yet on a documented cadence (L2 Q2 Partial); the quarterly red-team-the-library exercise is not yet operational (L2 Q3 No). The cumulative multiplier correctly suppresses L2 credit because L1 is not complete, a healthy signal that prevents the program from claiming downstream maturity it has not earned.

28. The questionnaire

The 108 questions follow. Each question has the same workbook layout: question text, answer field, evidence box, and notes box. Practice and level headings are repeated so the workbook is usable as a printout or as a standalone assessment instrument. Subsections 28.1 through 28.12 cover the 12 practices in the canonical Endpoints-domain order: SM, PC, EG, TA, SR, SA, DR, IR, ST, EH, IM, ML.

28.1 Strategy & Metrics (SM)

SM Level 1.

Q-SM-L1-1. Is there a published AI/HAI Endpoint Assurance program charter with a named executive sponsor (CISO co-sponsored by CIO / Head of IT), a cross-functional working group (Security, IT, Engineering, Product, Privacy/Legal, HR), and clear decision rights for approval, block, exception, and go-live across all seven endpoint AI archetypes (AI assistant/copilot, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-2. Does a single AI/HAI endpoint inventory exist, seeded from MDM, EDR, browser-extension admin, SaaS-admin console, identity-OAuth, customer-facing AI, mobile app store, and IoT asset-registry signals, covering all seven archetypes with ≥90% coverage of discovered endpoint AI assets within 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow endpoint AI ratio (≤15% and trending down), AUP attestation (≥95% of managed-endpoint users), assets with named owner (100%), and known data-exposure events from endpoint AI assets?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 2.

Q-SM-L2-1. Is every AI/HAI endpoint asset in the inventory assigned a risk tier based on the seven auditable dimensions (user population, data classes accessible, action capability, customer-data egress potential, deployment scale, regulatory scope, AI-content disclosure obligation), with a published tier-treatment matrix driving differential program intensity?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-2. Is there a published tier-treatment matrix driving differential controls across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier endpoint AI assets receiving full-scope treatment in the last 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-3. Does the quarterly scoreboard report per tier and per archetype (with Critical-tier unsanctioned endpoint AI explicitly tracked at zero), and does tier-movement get logged and reviewed by the program sponsor?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 3.

Q-SM-L3-1. Does inventory and tier assignment auto-update from live MDM, browser-extension admin, SaaS-admin, identity-OAuth, own-built app release, and IoT telemetry signals with a published data-quality SLO, and is ≥80% of curation handled automatically with exception-based human review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-2. Does the program publish a semi-annual external-benchmarking brief comparing the program against at least five peer-comparable metrics via CSA / OASIS / OWASP MASVS / sector ISACs, and does it drive program investment decisions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-3. Does the program contribute at least four substantive, anonymized artifacts per year to the endpoint-AI assurance ecosystem (CSA AI Safety Initiative, OWASP MASVS, OASIS, NIST AI RMF, EU AI Act transparency guidance, sector ISACs), and does the executive/board ROI narrative cite external benchmarks?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.2 Policy & Compliance (PC)

PC Level 1.

Q-PC-L1-1. Have the three priority AI/HAI endpoint policies been published and formally approved, Endpoint AI Acceptable Use Policy (sanctioned tools, personal-account prohibition, data-class restrictions, own-built surface intake requirement), AI Browser-Extension Policy (allowlist enforcement, DLP integration, per-extension data-class annotation), and Customer-Facing AI Endpoint Disclosure Policy (Art. 50 disclosure UX requirements, accessibility standards, sector overlays, deployer-duty owner requirement), and is there a one-page compliance map tracing each priority requirement (EU AI Act Art. 50/26/9/Annex III, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, HIPAA/PCI-DSS/FERPA/COPPA) to the specific policy that carries it?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-2. Is the intake gate operational with a per-archetype artifacts checklist, a required disclosure UX review for customer-facing AI surfaces, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months have a gate record (100% for Critical/High)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-3. Are ≥95% of managed-endpoint users covered by a current-year Endpoint AI AUP acknowledgment, and does every own-built customer-facing or decision-affecting AI endpoint surface in production have a named deployer-duty owner logged in the SM-Endpoints inventory with a disclosure UX record on file?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 2.

Q-PC-L2-1. Have the three priority policies been extended with tier-specific addenda, and do Critical customer-facing AI surfaces carry explicit executive plus privacy-officer sign-off at go-live with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and current disclosure UX attestation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-2. Is a compliance evidence bundle continuously maintained for every Critical/High endpoint AI asset with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days, including a current disclosure UX attestation for all Critical customer-facing AI surfaces?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing go-live artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA as applicable) complete and current for in-scope assets?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 3.

Q-PC-L3-1. Does a continuous attestation pipeline auto-update evidence bundles from MDM events, SaaS-admin AI-feature signals, browser-extension policy changes, own-built AI surface deployment events, and edge-device firmware events, with an attestation currency SLO of ≤24 hours and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High assets continuously attested?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Endpoints detection trends + IM-Endpoints incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update, and are EG-Endpoints training materials updated within 30 days of any policy change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI endpoint policy and transparency topics (EU AI Act Art. 50 implementing guidance, GDPR EDPB AI guidance, NIST AI RMF Playbook, OASIS, CSA, sector regulators), with documented external recognition?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.3 Education & Guidance (EG)

EG Level 1.

Q-EG-L1-1. Have all managed-endpoint users completed a current-year endpoint AI literacy course covering the seven endpoint AI archetypes (with org-specific examples), the Endpoint AI AUP data-class restrictions (including personal-account prohibition, regulated data in AI prompts, productivity AI and browser extension hygiene), and the shadow AI disclosure path, with ≥95% completion and content updated within 30 days of any policy or archetype change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-2. Has the endpoint AI reviewer population (endpoint security engineers, IT MDM/EDR admins, product security engineers for own-built surfaces, mobile AI engineers, edge AI engineers) completed role-based training covering all seven endpoint archetypes, EDR AI-egress detection, browser-extension review methodology, chatbot threat modeling (AGH/EA/TM/RA TTPs and Art. 50 disclosure UX review), mobile AI permission scope assessment (OWASP MASVS), and edge AI model-integrity verification, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 TTP misclassifications per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-3. Is a shadow-AI-on-endpoints 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 shadow AI disclosures to campaign channels, with disclosures rising in Q1-Q2 after launch then declining as the sanctioned-tool catalog grows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 2.

Q-EG-L2-1. Is there a scenario library of ≥30 anonymized real endpoint AI 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 TTP misclassification per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-2. Have channel-specific practitioner tracks (developer-endpoint AI, customer-support AI, mobile AI, edge AI) been delivered to ≥1 practitioner per Critical/High-tier asset in each applicable channel, with team-level training coverage tracked in the SM-Endpoints inventory?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-3. Are shadow-AI-on-endpoints campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 3.

Q-EG-L3-1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CSA AI Safety Initiative, OWASP MASVS, OASIS, or sector ISAC) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-2. Is a monthly live calibration cadence operating (anonymized endpoint AI intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier endpoint AI reviewers hold an external AI-assurance or endpoint-AI credential where one exists?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-3. Does the program contribute ≥2 substantive artifacts per year to industry endpoint AI certification or curriculum working groups, and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel endpoint AI observations exist?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.4 Threat Assessment (TA)

TA Level 1.

Q-TA-L1-1. Are there published, versioned threat models for all seven endpoint AI archetypes (AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device), each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, applicable OWASP LLM / Agentic / MASVS / Browser-Extension references, and PC-Endpoints compliance items, with a named library steward and a documented quarterly refresh cadence?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-2. Does every endpoint AI deployment entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), deployment-specific deltas (tool list, data classes accessible, tier, user population, Art. 50 disclosure obligation), top-5 threats with HAI TTP tags and ATLAS tactic IDs, and gaps for SR/SA follow-up, with 100% of newly Sanctioned deployments carrying a snapshot in the last 90 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-3. Is there a published shadow-endpoint-AI threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors, elevated threat scenarios for unsanctioned endpoint AI deployments, and the specific detections (MDM telemetry, egress monitoring, SaaS-admin audit logs, endpoint DLP signals) used to surface them?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 2.

Q-TA-L2-1. Does every Critical-tier endpoint AI deployment have a current-year per-deployment deep threat model (not an archetype snapshot) covering deployment-specific attack trees, an abuse-case catalog by adversary archetype, deployer-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on tool additions, sensor changes, or scope expansion?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-2. Is external AI endpoint threat intel (MITRE ATLAS updates, AVID, OWASP LLM / Agentic / MASVS / Browser-Extension revisions, sector ISACs, academic adversarial-ML venues, CSA endpoint AI outputs) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-3. Does the program run a quarterly red-team-the-library exercise that probes an in-scope endpoint AI deployment using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and an expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 3.

Q-TA-L3-1. Does the threat library auto-update from telemetry (ML-Endpoints detections, IM-Endpoints incidents) and external feeds (ATLAS, AVID, OWASP, CSA, academic) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / OWASP MASVS / Browser-Extension Top 10 / CSA endpoint AI security, with at least two externally recognized in published advisory or standard revisions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-3. Are anonymized endpoint archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, OWASP AI chapter, CSA endpoint working group, or sector ISAC AI working group) tied to the library?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.5 Security Requirements (SR)

SR Level 1.

Q-SR-L1-1. Is there a published, versioned AI/HAI Endpoints Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Endpoints archetype threat and one PC-Endpoints priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per deployment at intake?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-2. Do 100% of new endpoint AI deployments approved in the last 90 days have a completed Requirements-Evidence Map (REM) on file, with every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific verifiable evidence (MDM policy screenshot, admin-console state, extension scope review, attestation log), each Gap-accepted row naming a compensating control, owner, and re-review date, and material-change triggers defined for when the REM must be re-reviewed?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-3. Is the pack on a quarterly refresh cadence with a named owner, are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements from scratch, and is cross-Vendors-domain REM linkage operating for Critical-tier endpoint AI sourced from external vendors?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 2.

Q-SR-L2-1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (kill-switch test age, no-train re-verification cadence, DLP coverage percentage, attestation failure alert time) and binary state (SSO + MFA confirmed, Art. 50 disclosure red-team tested, extension scope review complete, model signing verified) specified, and has all qualitative "appropriate" and "reasonable" language been removed from the pack?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-2. Are ≥95% of Critical-tier REMs re-validated against observed reality (MDM telemetry, SaaS-admin audit log, DLP signals, vendor admin-console API, attestation service logs) in the last 90 days, with validation deltas routed to IM-Endpoints and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-3. Does 100% of Critical-tier deployments carry a full EU AI Act Art. 26 deployer-duty checklist in their REM with verifiable evidence, and is the per-tier pack overlay enforced at SM intake, with Critical-tier deployments receiving full depth (including Art. 50 red-team probe and executive sign-off) and Low-tier receiving base pack only?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 3.

Q-SR-L3-1. Is the AI/HAI Endpoints Requirements Pack expressed in a machine-readable schema and enforced via endpoint-attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier deployments going live with a failing REM check, and the schema published under a permissive license with tracked external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-2. Are ≥70% of REM evidence rows auto-validated via MDM/UEM, SaaS-admin, DLP telemetry, and attestation service ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, endpoint AI requirement clauses) to recognized standards bodies (CSA endpoint AI / OWASP MASVS / NIST AI RMF Playbook / ISO AI security standards work), with contributions publicly documented and traceable to adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.6 Secure Architecture (SA)

SA Level 1.

Q-SA-L1-1. Are seven reference patterns published, one per archetype (AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device), each with a labeled deployment diagram, data-boundary definition, identity and auth model, DLP / egress controls, logging spec, and explicit row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-2. Are 100% of chatbot and conversational UI deployments verified (via ST-Endpoints test, not only UX screenshot) to have a persistent Art. 50 disclosure that cannot be suppressed, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training, with each entry tied to the real incident that generated it?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active endpoint AI deployments in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 2.

Q-SA-L2-1. Are the four tier-conditional extended patterns (Critical overlay, High overlay, multi-region, managed-endpoint enforcement) published as deployable MDM configuration profiles or SaaS-admin configuration baselines with conformance checks, and are ≥80% of Critical and High-tier endpoint AI deployments running on encoded patterns as confirmed by MDM compliance reporting and the SM inventory?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-2. Has the anti-pattern catalog been updated from ≥3 real IM-Endpoints incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance checking covering 100% of encoded deployments with findings tracked to resolution?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-3. Are 100% of Critical-tier deployments carrying explicit EU AI Act Art. 26 and Art. 50 control mappings in the pattern documentation, and is the tier-treatment matrix from SM L2 reflected in the pattern variants (Critical deployments get the Critical overlay including Art. 50 red-team probe and kill-switch MDM configuration, High deployments get the High overlay, Medium/Low follow the base pattern)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 3.

Q-SA-L3-1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Endpoints pattern controls aligned to ATLAS primary tactics TA0007 Privilege Escalation, TA0008 Defense Evasion, TA0011 Exfiltration, and TA0005 Persistence, and is there an active ATLAS practitioner engagement cadence?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-3. Is there at least one documented reference to SA-Endpoints patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.7 Design Review (DR)

DR Level 1.

Q-DR-L1-1. Is there a published, versioned per-archetype AI/HAI Endpoints Design Checklist, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with archetype-specific items covering managed-endpoint requirement, tool-allowlist, DLP scope, vendor no-train probing, Art. 50 disclosure, kill-switch path, and affected-persons rights surface?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-2. Do ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before deployment begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Endpoints L1, and a residual-risk list with named owner and expiry in every record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA pattern-update and SR pack-update reviews, and does every IM-Endpoints incident trigger a re-examination of the DR record that approved the affected endpoint?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 2.

Q-DR-L2-1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Endpoints per-artifact deep models and anonymized IM-Endpoints incidents, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-2. Is a SaaS-AI handoff review required before every tenant-wide AI feature enablement, confirming the enable workflow, approval chain, per-feature data-scope declaration, conditional-enablement configuration, and drift-detection hook are in place and documented in the DR record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-3. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using MDM telemetry, browser admin policy state, SaaS admin audit feeds, mobile MDM, and edge device attestation reports, with 100% of material drifts automatically re-routed to DR for a new review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 3.

Q-DR-L3-1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily automated attestation signal, checking MDM policy compliance, browser-policy enforcement, SaaS-admin feature state, Art. 50 disclosure presence, and device signature currency, with deviations auto-opening DR-exception tickets triaged within 3 business days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented adoption and internal practice aligned to the published versions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS updates, OWASP MASVS revisions, sector ISAC advisories) and internal signals (IM-Endpoints incidents, ML-Endpoints telemetry, ST-Endpoints findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.8 Implementation Review (IR)

IR Level 1.

Q-IR-L1-1. Is there a published, per-archetype IR checklist, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), covering MDM-policy-matches-design verification, config-matches-DR verification, SR REM evidence currency check, logging-flow verification to SIEM, and kill-switch test execution, with the chatbot checklist verifying Art. 50 disclosure in the live UX and the edge device checklist verifying firmware / model signature currency and remote-disable function?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-2. Do 100% of new AI/HAI-enabled endpoints going to production in the last 90 days carry a deployment IR record, and do ≥90% of all active endpoints carry a current-year IR record, with material-change triggers wired to SM-Endpoints inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-3. Are findings severity-tagged and tracked in IM-Endpoints with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR REM row update before the finding is closed?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 2.

Q-IR-L2-1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints under continuous drift detection, via MDM webhook events, browser-policy state monitoring, SaaS-admin webhooks, mobile MDM scan deltas, and edge device attestation freshness, with median detection latency ≤7 days and automated finding creation on material deviations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-2. Are vendor no-train and data-handling settings verified via vendor admin APIs (Bedrock / Vertex / Azure OpenAI / OpenAI / Anthropic / SaaS-AI platforms) on a monthly (Critical) and quarterly (High) probing cadence, not from contract language alone, covering ≥80% of Critical/High-tier endpoints, with deltas from the previous probe opening IR findings with severity matching the data-class impact?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-3. Are ≥95% of SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR within 24 hours, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Endpoints L2 tier-treatment matrix SLAs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 3.

Q-IR-L3-1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily attestation signal across all three dimensions (pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Endpoints tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-2. Has the program published per-archetype configuration baseline schemas to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical endpoint per year trending down over two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-3. Is the post-incident IR feedback loop operational, with IM-Endpoints post-incident reviews including a mandatory IR-record re-examination step, and ≥1 attestation rule update produced per material incident, ensuring incident learning continuously improves the attestation coverage?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.9 Security Testing (ST)

ST Level 1.

Q-ST-L1-1. Is a per-archetype foundational test battery published for all seven AI/HAI endpoint archetypes, with each test class tied to a TA-Endpoints archetype threat (HAI TTP + ATLAS tactic ID) and an SR-Endpoints requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI-enabled endpoints required to pass the battery before production Sanctioned status is issued?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-2. Are six regression corpora (prompt-injection, jailbreak, multi-modal injection, DLP-paste-block, browser-extension-scope, Art. 50 disclosure) versioned in source control, with a named corpus owner, a monthly refresh cadence from internal and external sources, and runs triggered on deployment updates for Critical/High-tier endpoints, and is the Art. 50 disclosure corpus re-run on every UX release for customer-facing chatbots and multi-modal interfaces?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-3. Are all test failures routed to IM-Endpoints within 1 business day with a severity tag and named owner, and does TA-Endpoints archetype threat coverage by the test battery and corpus reach ≥80% by end of year one?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 2.

Q-ST-L2-1. Are 100% of Critical-tier AI/HAI-enabled endpoints red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Endpoints L2 per-artifact deep threat models, covering prompt-injection chains, multi-modal injection, DLP bypass, Art. 50 disclosure circumvention, tool-allowlist escape, extension-scope violation, data-exfiltration probes, and physical-interface attacks for applicable archetypes, with findings routed to IM and remediation tracked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-2. Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora on every deployment update; Low-tier: prompt-injection corpus on deployment), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-3. Are cross-archetype composition tests (AI assistant + browser extension; chatbot + multi-modal) documented and executed for all Critical-tier composite endpoints, and is per-tier SLA adherence for testing activities ≥90%?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 3.

Q-ST-L3-1. Are ≥80% of Critical-tier AI/HAI-enabled endpoints under continuous automated adversarial testing with daily probe execution, covering prompt injection, multi-modal injection, DLP-bypass generation, extension-scope probing, and Art. 50 disclosure monitoring, with novel TTPs triaged into the TA-Endpoints library within 14 days and high-severity automated findings routed to IM within 24 hours?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, OWASP MASVS, or OWASP Browser-Extension Top 10, and are all six open regression corpora published under a permissive license and maintained upstream with documented external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-3. Is the Art. 50 disclosure daily probe covering 100% of in-scope customer-facing chatbot and multi-modal interfaces, and has the program hosted at least 1 industry endpoint AI red-team benchmark per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.10 Environment Hardening (EH)

EH Level 1.

Q-EH-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 2.

Q-EH-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 3.

Q-EH-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.11 Issue Management (IM)

IM Level 1.

Q-IM-L1-1. Is there a single AI/HAI endpoint issue backlog with standardized metadata (source, affected archetype linked to SM-Endpoints inventory, severity rubric anchored to AI-endpoint-specific axes, active regulated-data exfiltration via AI / Art. 50 disclosure suppression at scale / edge tamper with ongoing operation / GDPR Art. 33 trigger for Critical; confirmed control failure with potential impact for High, etc., owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA-Endpoints, SR-Endpoints, DR-Endpoints, IR-Endpoints, ST-Endpoints, ML-Endpoints, external)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-2. Is the AI/HAI endpoint incident playbook published with ≥7 named AI-specific endpoint incident classes (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-3. Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA (60d), PCI-DSS endpoint breach, COPPA, FERPA, and sector-specific obligations, with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 2.

Q-IM-L2-1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier archetype briefing, and tier-movement in the SM-Endpoints inventory automatically triggering IM-Endpoints configuration updates (on-call path, playbook variant, SLA targets) within 14 days of a Critical re-tier event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML-Endpoints practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents, with named cross-domain contacts for Software, Data, and Processes domains verified quarterly, a single Incident Commander from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 3.

Q-IM-L3-1. Does the program contribute ≥4 anonymized AI endpoint-incident-classification entries per year to sector ISACs, ≥2 contributions per year to CSA Endpoint AI Safety Initiative or OWASP MASVS, and ≥1 contribution per year to MITRE ATLAS Endpoints-tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-2. Are ≥3 pre-authorized automated containment actions live (extension force-remove, SaaS-AI feature disable, edge-device remote-disable, or chatbot rate-limit tighten classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-3. Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.12 Monitoring & Logging (ML)

ML Level 1.

Q-ML-L1-1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each 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), and has compliance of each production archetype been measured against it within the last quarter, with gaps on the IM-Endpoints backlog?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, and last-tuned date, including regulated-data paste-attempt detection, customer-data egress via AI assistant, unsanctioned browser extension, SaaS-AI shadow-enablement, mobile-app local-model integrity failure, edge-device tamper / attestation failure, chatbot Art. 50 disclosure suppression, chatbot abuse-pattern at scale, and cross-tenant SaaS-AI data exposure, with false-positive rates tracked per detection and monthly tuning reviews occurring?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-3. Has the evidence trail for EU AI Act Art. 12 and Art. 50, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Endpoints log store, including sector overlays (COPPA for children-facing endpoints, FERPA for educational endpoints, sector mobile-banking regulations) where applicable, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production endpoint archetype can be assembled within the ≤24-hour SLA?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 2.

Q-ML-L2-1. Is tier-calibrated logging depth applied per the SM-Endpoints L2 tier-treatment matrix, Critical-tier archetypes retaining full interaction-event and DLP-decision log corpora at the longest regulatory window, Low-tier archetypes receiving baseline only, and is this calibration automatically updated when an archetype is re-tiered (Critical re-tier within 14 days; other tiers within 30 days)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-2. Is the SIEM ingesting ML-Endpoints log feeds with ≥3 cross-archetype correlation rules active (covering at minimum multi-archetype data-exfiltration chain, browser-extension to SaaS-AI lateral move, and chatbot abuse escalation chain), and is a quarterly detection tuning cycle operating from IM-Endpoints post-incident and ST-Endpoints finding inputs, with external advisory updates from ATLAS endpoint techniques, OWASP MASVS, app-store flags, and edge-device CVEs reviewed quarterly?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-3. Are ≥90% of Critical/High-tier endpoint archetypes running anomaly-detection baselines with behavioral profiles refreshed monthly and FP rates tracked and trending down, and is the ML-Endpoints logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier archetypes in PC-Endpoints compliance evidence bundles?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 3.

Q-ML-L3-1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic endpoint-AI log data (including SaaS-AI admin-audit formats, edge-device attestation events, and mobile-AI integrity events), and is detection coverage auto-verified for 100% of new or re-tiered SM-Endpoints inventory entries within 24 hours of the inventory change event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-2. Are ≥90% of Critical/High-tier endpoint archetypes running anomaly detection on endpoint-AI behavioral patterns (DLP-decision sequences, extension-install behavior, SaaS-AI feature-usage patterns, edge attestation cadence, mobile integrity failure clusters), with anomaly models retrained monthly on production log data, model versions tracked in the ML-Endpoints model registry, and anomaly alerts feeding the IM-Endpoints backlog through the same detection-to-ticket pipeline as rule-based detections?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-3. Has the program contributed ≥2 telemetry-standard artifacts per year to the CSA Endpoint AI Safety Initiative or equivalent and ≥12 anonymized detection signatures per year to sector ISACs, with contributions maintained current, legally vetted, and tracked for external adoption, and have OWASP MASVS contributions for mobile AI app integrity detection patterns been submitted and are in-progress or published?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

29. Practice-level rollup

After completing all 108 questions, the assessment team fills in the table below. For each practice, the team counts Yes (Y), Partial (P), and No (N) answers per level. The team computes the precise score as described in Section 27: L1_score = (Y + 0.5P) / 3; L2_score = (Y + 0.5P) / 3 × L1_score; L3_score = (Y + 0.5P) / 3 × L2_score; Practice Score = L1_score + L2_score + L3_score.

Worked example

The assessment team answers for TA-Endpoints: L1 Q1 = Y, L1 Q2 = Y, L1 Q3 = P; L2 Q1 = Y, L2 Q2 = P, L2 Q3 = N; L3 all N.

L1_score = (1.0 + 1.0 + 0.5) / 3 = 0.833
L2_score = (1.0 + 0.5 + 0.0) / 3 × 0.833 = 0.417
L3_score = 0.0

TA Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: TA-Endpoints scored L1 = 0.83, L2 = 0.42, L3 = 0.0, yielding a practice maturity of 1.25, solidly Foundational with partial L2. The seven archetype threat library and the per-intake snapshot gate are working; the shadow-endpoint-AI threat view is incomplete; the external endpoint AI threat intel triage cadence is partial and the red-team-the-library exercise is not yet operational. Roadmap priority for the practice: complete the shadow-endpoint-AI threat view (closes the L1 Partial), operationalize external endpoint AI intel triage from MITRE ATLAS / OWASP MASVS / Browser-Extension Top 10 / CSA (L2 Q2), launch the red-team-the-library cadence against a Critical-tier customer-facing chatbot (L2 Q3). L3 work, auto-update pipelines and industry contributions, is premature at this score.

Notes column for assessor. Use the space below to record per-practice observations: which questions were hardest to answer, where evidence was thin, where Partial answers cluster, and what the most actionable next step is.

SM: _________ PC: _________ EG: _________ TA: _________ SR: _________ SA: _________ DR: _________ IR: _________ ST: _________ EH: _________ IM: _________ ML: _________

30. Domain-level rollup

Domain Maturity = (sum of all 12 Practice Scores) / 12 = ____ / 3.0

Maturity band achieved: ☐ Ad-hoc (0.0–0.9) ☐ Foundational (1.0–1.9) ☐ Comprehensive (2.0–2.9) ☐ Industry-Leading (3.0)

Per-Business-Function rollup

A domain is mature when all four Business Functions are at the same band. An Endpoints domain whose Operations function trails the others has built and verified well but cannot run the program in production, MDM and SaaS-admin baselines drift, anomaly detection goes stale, and the on-call rotation cannot tell a Critical-tier customer-facing chatbot from a Low-tier developer coding assistant. A domain whose Verification function trails ships customer-facing chatbots without Art. 50 disclosure proof and ships mobile AI apps without MASVS-aligned testing. The most common pattern in early-stage endpoint AI programs is Governance ahead of Building, and both ahead of Verification and Operations, because the three priority policies (AUP, Browser-Extension, Customer-Facing Disclosure) are easier to write than red-team corpora are to maintain and SaaS-admin AI-feature drift detection is to operationalize.

Worked example, domain-level rollup

The following shows a plausible result for an organization 18 months into its Endpoints-domain program.

Domain Maturity = 14.67 / 12 = 1.22 / 3.0

Band: Foundational. This organization has crossed L1 across most practices but has not yet closed L2 for any practice. The Operations function is weakest (EH 0.83, ML 0.75 both sub-Foundational), which is typical when the inventory exists and the policies are published but MDM AI-tool allowlist enforcement, browser-policy DLP coverage, and the per-archetype endpoint-AI logging baseline have not yet been operationalized at scale. The program has a visible inventory and published policies for AUP, browser extensions, and customer-facing disclosure, but the hardening controls and logging baselines for SaaS-AI productivity features and edge AI devices are not consistently measured.

Per-Business-Function summary for this example:

The imbalance is clear: Governance is at 1.70 while Operations is at 0.89. The program has published good policies and built an inventory but has not yet instrumented its own endpoint AI surface for continuous attestation and anomaly detection. The roadmap should front-load EH L1 (MDM AI-tool allowlist, DLP tuned for AI exfiltration patterns, Art. 50 disclosure verification, edge device signing) and ML L1 (per-archetype logging baseline, high-signal detection set, deployer-duty evidence trail) before deepening Governance to L2. Verification will follow Operations naturally once IR and ST have continuous signal sources to consume from EH and ML.

Strengths

Gaps

Highest-priority remediation areas (top 5)

31. Improvement roadmap template

The team uses this template to convert assessment findings into a 12-month roadmap. Each entry names a target gap, the practice and level it addresses, the owner, the success metric, and the deadline.

A 12-month roadmap for the Endpoints domain follows four natural quarters. The sequencing mirrors the dependency graph in HAIAMM v3.0 §9: Governance must be in place before Building can operate; Building must be in place before Verification can produce meaningful results; Operations depends on all three preceding functions. In the Endpoints domain, the SM-Endpoints inventory is the load-bearing artifact every other practice consumes, without the seven-archetype inventory, the PC priority policies have nothing to govern, the TA archetype models have nothing to attach to, and the EH MDM/SaaS-admin baselines have nothing to enforce against.

Quarter 1 (months 1–3). Stabilize L1 across the four Business Functions. Priority practices: SM L1, PC L1, EG L1, TA L1.

Quarter 1 focus: make every AI/HAI endpoint asset visible, named, and governed across all seven archetypes. The charter, the seven-archetype inventory, the three priority policies (Endpoint AI AUP, Browser-Extension Policy, Customer-Facing AI Endpoint Disclosure Policy), and the archetype threat library must all exist at L1 before IT and product teams can self-serve on intake. A shadow-endpoint-AI discovery sweep should run within the first 30 days, pulling from MDM app catalogs, browser-extension admin consoles, SaaS-admin AI-feature dashboards, identity-OAuth events, and mobile MDM, so the inventory is seeded from signals rather than declared from memory.

Quarter 2 (months 4–6). Complete remaining L1 practices. Priority practices: SR L1, SA L1, DR L1, IR L1, ST L1, EH L1, IM L1, ML L1; SM L2 risk-tier rubric.

Quarter 2 focus: close the Building, Verification, and Operations L1 gaps, and begin the L2 calibration work starting with the SM-Endpoints risk-tier rubric, which is the prerequisite every other practice needs to move to L2. EH L1 in particular needs early attention because MDM AI-tool allowlists, DLP rules tuned for AI-specific exfiltration patterns, and Art. 50 disclosure verification on customer-facing chatbots cannot wait for L2.

Quarter 3 (months 7–9). Operationalize L2 across the Governance and Building functions. Priority practices: PC L2 evidence bundles, TA L2 per-deployment deep models, SA L2 MDM-encoded patterns, DR L2 scenario-based walkthroughs, SR L2 quantitative requirements.

Quarter 3 focus: the tier rubric now exists, the program uses it. Compliance evidence bundles for Critical/High customer-facing chatbots and SaaS-AI productivity surfaces should be assembling continuously. Deep threat models for Critical-tier replace archetype snapshots. Design reviews for Critical-tier customer-facing surfaces move to scenario-based walkthroughs anchored to TA per-deployment models and anonymized IM incidents. The SR pack sheds all qualitative language in favor of quantitative SLAs and binary states.

Quarter 4 (months 10–12). Complete L2 across all 12 practices and prepare L3 entries for selected practices. Priority practices: IR L2 continuous drift detection, ST L2 quarterly red-team cadence, EH L2 identity-layer conditional access for Critical endpoints, ML L2 anomaly detection, IM L2 tier-calibrated playbook; begin L3 scope decisions for SM, TA, and EG.

Quarter 4 focus: close the Verification and Operations L2 gaps. Continuous drift detection from MDM webhook events and SaaS-admin webhooks, quarterly red-team of Critical-tier customer-facing chatbots and mobile AI apps, identity-layer enforcement of managed-endpoint requirement (not just MDM-layer), tier-calibrated anomaly baselines for SaaS-AI behavioral patterns, and a tier-calibrated incident response playbook with Critical-tier MTTA ≤1 hour are the five load-bearing L2 capabilities most programs defer because they require engineering investment in the MDM/EDR/SaaS-admin/identity substrate. The L3 scope decisions for SM, TA, and EG can be made now even if the automation work begins in year 2.

Reassessment date (12 months from this assessment): ____

When the next annual assessment runs, the assessment team compares practice scores to this baseline. The expected trajectory for a program executing this roadmap is: Domain maturity moves from the Foundational band toward the low end of the Comprehensive band (1.6 to 2.0). The Operations function moves from Ad-hoc to Foundational, the most common single-year jump possible for an Endpoints program once MDM AI-tool allowlists, AI-tuned DLP, the per-archetype endpoint AI logging baseline, and the high-signal detection set are in place. The Governance function moves from mid-Foundational to low-Comprehensive as the three priority policies acquire tier-specific addenda and continuous compliance evidence bundles attach to Critical customer-facing chatbots. The largest score gains come from practices where the Q1–Q2 L1 foundation was weakest: typically IR, EH, and ML in the Endpoints domain, because these three depend on the MDM/EDR/SaaS-admin/identity substrate being instrumented for AI-specific signals rather than only generic endpoint and SaaS telemetry.

Part V, Reference

32. Glossary

Endpoint AI Acceptable Use Policy. The first of the three priority AI/HAI endpoint policies. Enumerates sanctioned AI tools, prohibits personal-account use for org AI work, restricts data classes by tool category, gates browser extensions to the allowlist, restricts SaaS-AI feature enablement, and requires intake for any own-built customer-facing AI surface.

AI Browser-Extension Policy. The second priority policy. Operates allowlist-only enforcement via browser enterprise policy, governs per-extension scope review, integrates with browser-level DLP, requires removal of discovered unapproved extensions, and logs exceptions.

Customer-Facing AI Endpoint Disclosure Policy. The third priority policy. Applies to all own-built AI surfaces interacting directly with end users (chatbots, conversational UIs, voice AI, multi-modal AI, AI-augmented support), mandates user notification per EU AI Act Art. 50, requires synthetic-content marking, sets accessibility standards (WCAG 2.1 AA), and integrates with the intake gate.

AI/HAI endpoint archetype. One of seven categories of AI-enabled endpoint or user-facing AI interface: 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.

AI/HAI endpoint inventory. The single source of truth for all AI/HAI endpoint surfaces the organization operates or governs, owned by the program lead. Seeded from MDM, EDR, browser-extension admin, SaaS-admin AI-feature consoles, identity-OAuth events, mobile MDM, edge device registries, and self-attestation.

Critical / High / Medium / Low. The four risk tiers introduced at SM-Endpoints L2. Driven by user exposure, data sensitivity processed on endpoint, decision-affecting use, agentic capability on endpoint, endpoint criticality (BYOD vs. managed), regulatory scope, and distribution scale.

Deployer-duty owner. The named individual or role accountable for EU AI Act Art. 26 deployer duties for an own-built customer-facing endpoint AI surface, disclosure UX, oversight assignment, monitoring, log retention.

Disclosure UX. The user-interface implementation of EU AI Act Art. 50 transparency obligation on a chatbot, conversational UI, voice AI, or multi-modal interface, clear, prominent, accessible, persistent across sessions, tested in ST.

EA, Excessive Agency. One of the four HAI-specific TTPs. In Endpoints terms, endpoint AI granted broader scope than the use case requires.

AGH, Agent Goal Hijack. One of the four HAI-specific TTPs. In Endpoints terms, prompt injection at user-facing AI surfaces redirects the AI's purpose.

HAI TTPs (EA, AGH, TM, RA). The four AI-specific threat-tactic categories carried throughout HAIAMM v3.0: Excessive Agency, Agent Goal Hijack, Tool Misuse, Rogue Agents.

MDM / UEM. Mobile Device Management / Unified Endpoint Management. The substrate enforcing AI-tool allowlist, browser policy, DLP for AI, and mobile AI app governance on managed endpoints. Examples: Jamf, Intune, Kandji, VMware Workspace ONE.

No-train flag. A vendor configuration setting indicating the vendor will not use customer data to train its AI models. Verified at intake via admin-console state (not contract text alone) and re-verified recurrently.

Priority compliance map. A one-page artifact tying each priority regulatory requirement to the specific organizational policy that carries it.

RA, Rogue Agents. One of the four HAI-specific TTPs. In Endpoints terms, autonomous AI on endpoints drifts from intended behavior over time.

Reference pattern. A vetted "green path" architecture pattern published per AI/HAI endpoint archetype. IT and product teams reach for the pattern first; deviations require design review.

REM, Requirements-Evidence Map. A per-deployment map that records, for each applicable requirement in the AI/HAI Endpoints Requirements Pack, whether the requirement is Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, with a citation to evidence.

SaaS-AI silent enablement. The pattern in which a productivity or collaboration SaaS vendor enables an AI feature tenant-wide without explicit organizational action, frequently giving the AI access to broader data scope than the org has reviewed. A primary L1 outcome metric tracks zero unsanctioned silent enablements in Critical-tier tenants.

Shadow endpoint AI. Ungoverned AI on endpoints and user-facing surfaces, unsanctioned browser extensions, SaaS-AI features silently enabled, mobile AI apps installed without inventory, edge AI deployed without IT. The program's primary L1 outcome is to make these visible, attributable, and trending down.

Shadow-endpoint-AI ratio. Unsanctioned AI/HAI endpoint surfaces in production divided by total endpoint AI surfaces in production. A primary L1 outcome metric. Reported quarterly and trending down; reported per tier at L2.

TM, Tool Misuse. One of the four HAI-specific TTPs. In Endpoints terms, endpoint AI tools or APIs invoked for attacker purposes.

33. Reference frameworks

This handbook is one of six domain handbooks that, together with a master handbook, constitute HAIAMM v3.0. The frameworks named here are referenced throughout. They are listed by name only; consult the issuing body's current published version when running an assessment.

Maturity-model lineage.

• OWASP SAMM (Software Assurance Maturity Model). HAIAMM borrows SAMM's lifecycle shape (Governance, Building, Verification, Operations) and practice-per-function structure.
• BSIMM (Building Security In Maturity Model). HAIAMM borrows the observational "this is what organizations actually do" posture at higher maturity levels.

AI-governance and endpoint frameworks (complementary).

• NIST AI RMF 1.0 + Playbook. GOVERN, MAP, MEASURE, and MANAGE align closely to Endpoints-domain practices.
• ISO/IEC 42001 (AI Management System). A management-system standard for AI. HAIAMM Endpoints-domain practices supply endpoint operational evidence an ISO 42001 AIMS requires.
• ISO/IEC 27001 / 27002. Annex A.8.1 (user endpoint devices), A.8.7 (malware protection), A.8.19 (installation of software on operational systems) apply.
• CSA AI Safety Initiative / AI Controls Matrix. Cross-organization AI controls work; HAIAMM contributes endpoint AI controls at L3.
• OWASP MASVS (Mobile Application Security Verification Standard). Mobile AI app security controls.
• OWASP Top 10 for LLM Applications / Agentic AI Top 10. Threat references relevant to chatbots, AI assistants, multi-modal interfaces.
• OWASP Browser-Extension Security Top 10. Browser-extension governance reference for browser-based AI tools.
• CIS Critical Security Controls. Endpoint hardening benchmarks adaptable to AI-capable endpoints.
• OpenSSF AI. Open Source Security Foundation working group on AI, supply-chain security for endpoint AI software.

Regulations applicable to AI/HAI endpoints.

• EU AI Act. Articles 9 (risk management), 26 (deployer duties), 50 (transparency), Annex III (high-risk classification).
• GDPR. Articles 22 (automated decision-making), 25 (privacy by design), 32 (security of processing), 33 (breach notification).
• SOC 2. CC6 logical access controls.
• HIPAA (where applicable). Safeguards on endpoint AI processing PHI.
• PCI-DSS (where applicable). Controls on endpoint AI in the cardholder data environment.
• COPPA / FERPA (where applicable). Children-facing and educational endpoint AI obligations.
• Sector-specific. FINRA model-risk for AI-enabled financial endpoints; FDA AI/SaMD for clinical endpoints; NYDFS Part 500.

Threat taxonomies.

• MITRE ATLAS (Adversarial Threat Landscape for AI Systems). Canonical adversarial-ML reference. Endpoints-domain TA consumes ATLAS technique IDs (notably AML.T0024 ML inference exfiltration and AML.T0051 LLM prompt injection) and contributes back endpoint-specific techniques at L3.
• AVID (AI Vulnerability Database). AI vulnerability disclosure database.
• OWASP LLM Top 10 and Agentic AI Top 10. Threat references for chatbot, AI assistant, multi-modal archetypes.
• OWASP MASVS. Mobile AI app threat and control reference.
• OWASP Browser-Extension Security Top 10. Browser-based AI tool threat reference.

Industry communities.

• CSA AI Safety Initiative. Cross-organization AI controls work.
• OASIS conversational AI / chatbot security standards. Standards body work on conversational AI security.
• OWASP AI chapter. Practitioner community for AI security.
• Sector ISACs. FS-ISAC (FinAI working group, mobile-banking AI endpoint), H-ISAC (ClinAI working group, patient-facing chatbot, mobile AI for health), IT-ISAC (managed-endpoint AI security).
• OpenTelemetry AI workgroup. Telemetry schema standards for AI endpoint events.

HAIAMM canonical companions.

• HAIAMM-v3.0-Framing.md, model master document; canonical definitions for the 12 practices, 6 domains, 3 maturity levels, cell template, dependency graph, through-lines, and authoring rules.
• AI-Attack-Taxonomy.md (HAA), high-impact AI attacks catalog cross-referenced to MITRE ATLAS.

Threat-tactic categories specific to HAIAMM (reproduced for reference).

• EA, Excessive Agency. Endpoint AI granted broader scope than the use case requires.
• AGH, Agent Goal Hijack. Prompt injection at user-facing AI surfaces redirects the AI's purpose.
• TM, Tool Misuse. Endpoint AI tools or APIs invoked for attacker purposes.
• RA, Rogue Agents. Autonomous AI on endpoints drifts from intended behavior over time.

34. Change log

End of HAIAMM v3.0 Endpoints Domain Handbook.