Monitoring & Logging (ML)

Endpoints Domain - HAIAMM v3.0

Practice Overview

Objective: Establish the logging baseline per AI/HAI endpoint archetype, operate a small high-signal detection set targeted at the top TA-Endpoints threats, 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 ≥6 months; GDPR Art. 30; sector overlays), 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, and an active tuning record. The full corpus produced by ML-Endpoints is the primary evidence artifact for PC-Endpoints' §10.2 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.

Maturity Level 1

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

At this level, the program makes every production AI/HAI endpoint archetype observable with a defined minimum event schema, closes the most dangerous detection gaps (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI shadow-enablement, chatbot abuse at scale, mobile-app integrity failure, edge-device tamper), and demonstrates that the resulting log corpus can produce deployer-duty evidence for regulators and auditors on demand.

Dependencies

• SM-Endpoints L1 (required): the AI/HAI endpoint inventory and archetype taxonomy define what must be instrumented; ML-Endpoints L1 cannot baseline what SM-Endpoints has not yet catalogued.
• SA-Endpoints L1 (required): reference patterns specify where logs originate (MDM telemetry, DLP management console, browser-policy telemetry, SaaS-admin audit log, chatbot gateway, mobile MDM event stream, edge device management console); the patterns specify what to log.
• EH-Endpoints L1 (required): hardened identity and endpoint-runtime controls (SSO enforcement, MDM AI-tool allowlist, DLP rules, rate-limit, integrity attestation) produce the events that ML-Endpoints captures; without EH-Endpoints instrumentation there are no usable log sources for DLP-decision or integrity events.
• TA-Endpoints L1 (required): archetype threat library drives detection priority; the high-signal detection set is selected from TA-Endpoints' top threat list, not invented independently.
• Supports / unblocks: IM-Endpoints L1 (detections become the primary runtime input to the endpoint issue backlog); PC-Endpoints L1 (ML-Endpoints log retention and export path constitutes the compliance evidence trail the PC-Endpoints priority compliance map requires).

Desired Outcomes

• Every production AI/HAI endpoint archetype emits the per-archetype minimum event schema; no archetype produces logs that are architecturally insufficient for deployer-duty evidence.
• Retention meets or exceeds the longest applicable compliance window across the active regulatory set; export SLA ≤24 hours demonstrated for each archetype at least annually.
• A small, bounded detection set is live, each detection tied to a named TA-Endpoints archetype threat and to at least one HAI TTP tag (EA / AGH / TM / RA) or ATLAS tactic; each with an owner, a query, an SLA, and a tuning record; false-positive rate tracked per detection.
• EU AI Act Art. 12 and Art. 50 log obligations, GDPR Art. 30 records-of-processing entries for customer-facing AI, and ISO/IEC 42001 AIMS evidence assets can be satisfied from ML-Endpoints log stores within the published SLA (on-demand pull ≤24 hours).
• Shadow-AI endpoints (unsanctioned browser extensions, SaaS-AI features silently enabled) are detectable from ML-Endpoints signals alone.

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. Each event record includes: 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. PII scrubbing applied per SR-Endpoints data-boundary requirements before logging.

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 event (DLP decision): data class detected, DLP rule applied, action taken (block / allow / redact), AI tool context, session-id, timestamp. - Tool-call event (for tool-using assistants): tool name, arguments (or argument hash for sensitive parameters), return value or hash, principal, session-id, success/fail, timestamp. - Admin-audit event: allowlist change (tool added or removed), configuration change, model-version change, session-policy change, principal, timestamp.

Browser-based AI tool: - Extension-install / extension-uninstall event: extension name, extension ID, install source, principal, endpoint-id, timestamp. - Extension-permission-grant event: permission type granted, extension ID, principal, timestamp. - DLP-decision event: data class, DLP rule applied, action taken, browser context (domain, page type), principal, timestamp. - Backend-SSO event: SSO sign-in or sign-out to AI tool via browser, principal, AI provider, result (success / failure / MFA challenge), timestamp.

Chatbot / conversational UI: - Customer-interaction event: session-id, AI step (intent classification, retrieval, generation, output-filter result), disclosure-shown flag (yes/no, disclosure-template-version), escalation-trigger-evaluated flag, escalation-triggered flag (yes/no), PII redacted from log (redaction rule applied), timestamp. Raw customer message content is not logged in clear-text if it contains regulated data. - Output-filter event: filter rule triggered, action taken (pass / block / redact), filter version, session-id, timestamp. - Abuse-detection event: pattern matched (jailbreak-attempt type, injection-pattern type, volume-anomaly flag), action taken (rate-limit trigger, session-block), session-id, timestamp.

Multi-modal AI interface: - Input event: modality (text / image / audio / video), content hash (not raw content for regulated data), validation-decision result (safe / flagged / blocked), validator version, session-id, timestamp. - Output safety-filter event: filter triggered (category, rule), action taken (pass / block / redact), filter version, session-id, timestamp. - Cross-modal consistency event: cross-modal check result (consistent / inconsistent), check type, session-id, timestamp.

AI-augmented productivity (SaaS-AI on endpoint): - Admin-audit event: AI feature-enablement change (feature name, previous state, new state, scope change, approver identity, change method, console vs. API vs. IaC), timestamp. - Per-feature usage event: feature name, principal, data-scope accessed (document / channel / mailbox scope), session-id, timestamp. - DLP-decision event for SaaS-AI data flows: data class detected in SaaS-AI input or output, DLP rule applied, action taken, feature name, principal, timestamp.

Mobile AI app: - App-launch event: app version, local-model version, principal, device-id, timestamp. - Permission-grant event: permission type (camera / microphone / location / storage), grant result (granted / denied), app version, device-id, timestamp. - Local-model integrity event: integrity check result (pass / fail), model hash verified, reference hash source, device-id, timestamp. - On-device action event: action type (inference request, data access, API call), data class of input, result, device-id, timestamp.

Edge AI device: - Boot-attestation event: device-id, firmware version, attestation result (pass / fail), TPM or HSM attestation token reference, sealed PCR values hash, timestamp. - Physical-tamper event: tamper sensor triggered (yes/no), tamper type if detected, device-id, IM-Endpoints alert routed (yes/no), timestamp. - Uplink event: device-id, connection result, data transmitted (class, volume), destination endpoint, timestamp. - Remote-disable event: trigger source (manual / automated / tamper-response), device-id, disable result, timestamp.

Admin-audit events (all archetypes): - MDM policy changes (AI-tool allowlist additions, removals, or modifications; device compliance policy changes). - Browser policy changes (extension allowlist modifications, AI site policy changes). - SaaS-admin AI feature changes (feature enablement, scope change, approval status change). - Vendor-configuration changes (no-train flag status change, data-processing configuration change). - Rate-limit and abuse-detection configuration changes (threshold changes, rule additions or removals).

Identity events (cross-archetype): - SSO sign-ins to AI provider management consoles, AI assistant admin consoles, SaaS AI admin panels, edge device management consoles: principal, provider, result (success / failure / MFA challenge), device posture check result (compliant / non-compliant / absent), timestamp. - Conditional-access decisions for AI surface access: policy applied, device posture result, access granted or denied, principal, timestamp.

Retention and exportability: - Retention window meets or exceeds the longest applicable requirement across active regulations: EU AI Act Art. 12 high-risk system logs ≥6 months; GDPR Art. 30 retention per data-class and processing purpose; HIPAA PHI where applicable ≥6 years; COPPA where children-facing endpoints are in scope; FERPA where educational endpoints are in scope; sector mobile-banking regulations where applicable. Where multiple windows apply, the longest governs. - Export path: JSON or structured CSV export from the log store tested at least annually; export SLA ≤24 hours for evidence requests from auditors, regulators, or legal hold. - Log integrity: write-once or append-only storage for admin-audit and deployer-duty evidence tiers; access-control separation between endpoint management teams and log store administrators.

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 detection has: owner, detection query, SLA (time-to-IM-Endpoints-ticket), and last-tuned date. False-positive rate tracked per detection; monthly tuning review.

Core detection set:

• Regulated-data paste-attempt blocked (high volume) (EA TTP), DLP block events for regulated-data paste into AI tool prompt fields exceed a threshold per user or per endpoint within a rolling window; high volume signals a user-training need and a potential policy-awareness gap; routes to IM-Endpoints and EG-Endpoints (training referral).
• Customer-data egress via AI assistant (ATLAS TA0013 Exfiltration / AGH TTP), 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 level routes immediately to IM-Endpoints as a High-severity finding.
• Unsanctioned browser extension installed (EA TTP), extension-install event where the extension ID is not present in the SM-Endpoints browser-extension allowlist; routes to IM-Endpoints for extension force-remove evaluation.
• SaaS-AI feature enabled tenant-wide without intake (shadow AI in SaaS) (EA TTP), SaaS-admin audit event recording a new AI feature enablement where no matching SM-Endpoints intake approval exists in the approval registry; routes to IM-Endpoints as a shadow-AI finding.
• Mobile-app local-model integrity failure, local-model integrity event where the integrity check result is fail; 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 tamper sensor triggered; routes immediately to IM-Endpoints for remote-disable evaluation.
• Chatbot EU AI Act Art. 50 disclosure suppression / failure, customer-interaction event where the disclosure-shown flag is false at session start for a scope where disclosure is required by the applicable Art. 50 determination; routes to IM-Endpoints as a compliance finding.
• Customer-facing chatbot abuse-pattern at scale (ATLAS TA0008 Defense Evasion / AGH TTP), abuse-detection events of type jailbreak-attempt or prompt-injection-attempt at volume above the threshold per session window or per time window; routes to IM-Endpoints for rate-limit tightening evaluation.
• Cross-tenant data exposure via SaaS-AI feature (TM TTP), 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 SM-Endpoints intake record; routes to IM-Endpoints as a Critical finding.

Each detection routes to the IM-Endpoints backlog on fire; median detection-to-ticket time target ≤1 hour for Critical-tier archetypes.

C) Produce and drill the deployer-duty evidence trail

ML-Endpoints is the primary evidence source for PC-Endpoints' §10.2 priority compliance map. At L1, 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)

Process Metrics (leading)

• Archetype-baseline gap list maintained, every production endpoint archetype scored against its archetype baseline; gaps on IM-Endpoints backlog with named owner.
• Detection tuning cadence, monthly review per detection; stale or superseded detections retired; new detection candidates from IM-Endpoints post-incident reviews queued.
• Retention / export test cadence, at least annually per archetype, with documented evidence.
• Deployer-duty drill cadence honored, quarterly, covering all archetypes in rotation.
• Sector-overlay compliance window review, annually; new sector-specific retention requirements applied within 90 days of regulatory effective date.

Effectiveness Metrics (business value)

• Incidents detected internally before external notification, trend over quarters.
• Regulator / auditor / legal evidence requests turned around inside the published SLA (≤24 hours).
• Shadow-AI endpoint discoveries initiated by ML-Endpoints detections (unsanctioned browser extension, SaaS-AI shadow-enablement) trending toward zero open undetected shadow-AI endpoints.

Success Criteria

• Per-archetype logging baseline published and instrumented for ≥90% of production AI/HAI endpoint archetypes.
• ≤12-detection high-signal set live, each with owner, detection query, SLA, 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 with SIEM for cross-archetype correlation; and feed incident-driven and ST-Endpoints-driven detection updates into a continuous tuning loop

At this level, monitoring intensity matches risk tier. Critical-tier endpoint archetypes receive full interaction-event and DLP-decision log corpora retained for the longest regulatory window; Low-tier archetypes receive the baseline only. The SIEM ingests ML-Endpoints log feeds and executes cross-archetype correlation rules. The detection set evolves continuously from IM-Endpoints post-incident reviews and ST-Endpoints findings rather than remaining static. Anomaly detection on endpoint-AI behavioral patterns supplements the rule-based set for Critical and High-tier archetypes.

Dependencies

• ML-Endpoints L1 (required): per-archetype logging baseline, detection set, and deployer-duty evidence trail must be operational before tier calibration is meaningful.
• SM-Endpoints L2 (required): risk-tier rubric (Critical / High / Medium / Low) and tier-treatment matrix drive per-tier logging depth and detection priority; without SM-Endpoints L2 tiers the calibration has no substrate.
• EH-Endpoints L2 (required): enhanced hardening at L2 (dedicated rate-limit, HSM-backed attestation, identity-layer managed-endpoint enforcement) produces richer identity and integrity signals; ML-Endpoints L2 consumes them for anomaly baselining.
• IM-Endpoints L1+ (required): post-incident reviews from IM-Endpoints feed detection tuning and new-detection requests into ML-Endpoints' review cycle.
• ST-Endpoints L1+ (required): security test findings (disclosure-suppression tests, DLP bypass tests, chatbot abuse tests, edge attestation bypass tests) identify gaps in the detection set and drive new detection candidates.
• Supports / unblocks: PC-Endpoints L2 (tier-calibrated compliance evidence bundles require ML-Endpoints L2 log-completeness signals); IM-Endpoints L2 (richer detections feed the tiered incident playbook with higher-fidelity severity signals).

Desired Outcomes

• Logging intensity visibly differentiates by tier: Critical-tier archetypes retain full interaction-event and DLP-decision log corpora for the longest regulatory window; Low-tier archetypes produce only the baseline schema.
• SIEM integration enables cross-archetype correlation, a single attacker session interacting with multiple AI/HAI endpoint archetypes in sequence surfaces as a correlated detection rather than isolated per-archetype alerts.
• The detection set evolves quarterly from a defined, governed feedback loop (IM-Endpoints post-incident reviews + ST-Endpoints findings + external advisory updates from ATLAS endpoint techniques, OWASP MASVS, browser extension store flags, mobile app store flags, edge-device CVEs).
• Anomaly detection establishes behavioral baselines for Critical and High-tier endpoint archetypes; rule-based detections that fire frequently without incident are refined or retired before the L2 cycle closes.

Activities

A) Tier-calibrated logging depth

Apply the SM-Endpoints L2 tier-treatment matrix to logging configuration:

• Critical tier: 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 tier: full interaction and DLP-decision events retained; standard admin-audit; core detections active; anomaly detection baselines established.
• Medium tier: interaction event hashes retained for regulatory window; standard admin-audit; shadow-AI emergence and baseline detections active.
• Low tier: 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 (per PC-Endpoints L2 staleness thresholds: ML-Endpoints logging-baseline validation ≤30 days for Critical).

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 at L2:
• Multi-archetype data-exfiltration chain: regulated-data DLP-allow event on an AI assistant (archetype 1) followed by a matching data-class access event on a SaaS-AI feature (archetype 5) from the same principal within the same session window, fires a correlated exfiltration-chain detection.
• Browser-extension to SaaS-AI lateral move: unsanctioned-extension-install detection on a browser-based AI tool (archetype 2) 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: chatbot abuse-pattern detection (archetype 3) 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.

C) Detection tuning loop: IM-Endpoints post-incident and ST-Endpoints feedback

Operate a quarterly detection review cycle: - IM-Endpoints post-incident reviews that touch a logging or detection gap generate a detection-update request (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) generate detection-gap findings routed to ML-Endpoints. - External advisory updates 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, edge-device CVEs with AI system impact; each applicable update either adds a detection candidate 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 in the set 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.

Outcome Metrics (L2)

Process Metrics (leading)

• Anomaly baseline refresh cadence honored (monthly for Critical; quarterly for High).
• SIEM correlation rule health monitored (rules producing alerts within expected frequency; no rule silent for >90 days without investigation).
• Detection-gap review calendar on schedule; IM-Endpoints and ST-Endpoints feedback queues reviewed at each quarterly cycle.
• Retention-tier calibration reconciled with SM-Endpoints inventory tier changes, when an archetype is re-tiered, logging depth updated within 14 days (Critical re-tier) or 30 days (other tiers).
• External advisory intake cadence, ATLAS endpoint-technique updates, OWASP MASVS, and app-store flags reviewed quarterly within 14 days of publication.

Effectiveness Metrics (business value)

• True-positive rate improvement quarter-over-quarter as detection tuning loop matures.
• Cross-archetype correlation incidents unified, multi-archetype data-exfiltration chains that would have appeared as isolated per-archetype findings at L1 now surface as correlated detections; reduces IM-Endpoints mean-time-to-understand (MTTU) for complex incidents.
• Compliance evidence bundle ML-Endpoints validation element completing inside PC-Endpoints staleness threshold with no manual intervention.

Success Criteria

• Tier-calibrated logging depth applied to 100% of SM-Endpoints inventory with current tier assignments; Critical-tier full corpus retention confirmed.
• SIEM integration live; ≥3 cross-archetype correlation rules active.
• Quarterly detection tuning loop operating with IM-Endpoints and ST-Endpoints feedback; ≥1 net change per cycle (new, updated, or retired detection).
• ≥90% of Critical/High-tier endpoint archetypes with anomaly-detection baselines; 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 with automated deployment; apply anomaly detection on endpoint-AI behavioral patterns; contribute anonymized detection signatures and telemetry schemas to CSA Endpoint AI Safety Initiative, OWASP MASVS, and sector ISACs

At this level, detections are version-controlled software artifacts deployed through CI/CD, not ad hoc SIEM queries. Anomaly detection on the full endpoint-AI behavioral corpus surfaces novel attack patterns that rule-based detections miss, DLP-decision sequences, extension-install patterns, edge attestation cadence anomalies, chatbot abuse-escalation progressions. The detection library and telemetry schemas are contributed back to the AI-assurance ecosystem, CSA Endpoint AI Safety Initiative, OWASP MASVS, and sector ISACs.

Dependencies

• ML-Endpoints L2 (required): tier-calibrated logging, SIEM integration, and detection tuning loop must be mature before automation is trustworthy.
• PC-Endpoints L3 (required): continuous compliance attestation pipeline consumes ML-Endpoints log signals; attestation SLO depends on ML-Endpoints L3 log freshness guarantees.
• SM-Endpoints L3 (required): automated inventory and tier-maintenance events trigger automated detection-set updates (new endpoint archetype at Critical tier auto-provisions the full detection set for that archetype).

Desired Outcomes

• Detection-as-code: every detection in the set is a version-controlled artifact deployed via the same CI/CD pipeline as the AI/HAI endpoint configuration it monitors; a merge request to a detection changes it in production.
• Anomaly detection on endpoint-AI behavioral patterns identifies attacker-session progressions, unusual DLP-decision volume shifts, novel extension-behavior sequences, and edge-device attestation anomalies that elude rule-based detections.
• The organization is a net contributor to AI-assurance endpoint telemetry standards: CSA Endpoint AI Safety Initiative detection patterns, OWASP MASVS verification criteria for mobile AI apps, and sector ISAC detection-sharing feeds.
• Industry peers can adopt contributed detection schemas and telemetry standards without significant adaptation.

Activities

A) Detection-as-code

• Every detection in the detection set expressed as a versioned, tested artifact in source control (detection query + metadata: owner, SLA, ATLAS-tactic tag, HAI-TTP tag, false-positive threshold, last-test-result).
• Detection CI/CD pipeline: changes to detection code trigger a test suite (unit tests over synthetic endpoint-AI event log data, integration tests against a log replay environment) before production deployment.
• Detection deployment via the same change-management pipeline as AI/HAI endpoint configuration; detection changes are reviewed, not applied ad hoc in the SIEM console.
• Detection coverage 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 if not.

B) Anomaly detection on endpoint-AI behavioral patterns

Apply unsupervised and semi-supervised anomaly models to the endpoint-AI behavioral corpus for Critical and High-tier archetypes:

• DLP-decision sequence anomaly: 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: extension-install patterns (install frequency, extension permission profile, install timing relative to DLP events) that fall outside the baseline distribution for the endpoint cohort, signals potential insider or compromised-account extension deployment.
• SaaS-AI feature-usage anomaly: 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 SaaS-AI feature.
• Edge-device attestation cadence anomaly: 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: cluster 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 retrained monthly; model retraining produces a new version in the ML-Endpoints model registry with lineage tracking.

C) Contribute detection signatures and telemetry schemas to industry

• CSA Endpoint AI Safety Initiative, 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); schema-spec format compatible with CSA contribution process; target ≥2 schema contributions per year.
• OWASP MASVS, contribute detection-pattern examples and verification criteria for mobile AI app security: 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.
• Sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), share anonymized, generalized detection signatures relevant to sector endpoint AI use (mobile-banking AI app integrity detection patterns for FS-ISAC; patient-facing chatbot abuse-detection patterns for H-ISAC); target ≥12 signatures per year; signatures 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)

Process Metrics (leading)

• Detection CI/CD pipeline health monitored; failed detection-deployment builds are on-call paged the same as production endpoint configuration failures.
• Anomaly model drift monitored (detection model performance against labeled incident records); retraining SLO met monthly.
• Contribution pipeline active, ≥2 telemetry-standard items in-flight (draft, in-review, or submitted) at any time.
• ISAC submission cadence, at least one anonymized detection signature submitted per month.

Effectiveness Metrics (business value)

• True-positive incidents surfaced first by anomaly detection (vs. rule-based or external notification), trending up quarter-over-quarter.
• Detection deployment lead time (merge to production) measured in hours, not weeks.
• Industry adoption of contributed endpoint-AI detection schemas tracked; citations, integrations, or standards-body acknowledgments documented.
• ISAC partner organizations citing contributed signatures in their own detection catalogs.

Success Criteria

• ≥90% of the detection set expressed as version-controlled, CI/CD-deployed artifacts; detection changes reviewed and deployed through the same change pipeline as AI/HAI endpoint configuration.
• 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 with anomaly detection active; anomaly models retrained monthly on schedule.
• ≥2 telemetry-standard contributions per year to CSA Endpoint AI Safety Initiative or equivalent; ≥12 anonymized detection signatures per year to sector ISACs; OWASP MASVS contributions tracked.

Key Success Indicators

Level 1: - Per-archetype logging baseline published and instrumented for ≥90% of production AI/HAI endpoint archetypes, covering session events, DLP-decision events, admin-audit events, identity events, and archetype-specific events (tool-call for AI assistants; extension-install for browser tools; disclosure-shown and abuse-detection for chatbots; input-modality and output-filter for multi-modal; SaaS admin-audit for SaaS-AI; app-launch and model-integrity for mobile; boot-attestation and tamper for edge). - ≤12-detection high-signal set live, each tied to a TA-Endpoints archetype threat and HAI TTP / ATLAS tactic tag, with owner, detection query, SLA, and monthly tuning record; false-positive rate tracked per detection. - Retention meets the longest applicable regulatory window (EU AI Act Art. 12 ≥6 months; GDPR Art. 30; sector overlays including COPPA, FERPA, sector mobile-banking); export SLA ≤24 hours tested annually; EU AI Act Art. 50 disclosure audit trail documented. - Quarterly deployer-duty drill executed and inside the ≤24-hour SLA; gaps routed to IM-Endpoints.

Level 2: - Tier-calibrated logging depth applied per SM-Endpoints L2 tier-treatment matrix; Critical-tier archetypes retain full interaction-event and DLP-decision log corpora at the longest regulatory window. - SIEM integration live with ≥3 cross-archetype correlation rules; ≥90% of Critical/High-tier archetypes with anomaly-detection behavioral baselines and FP rate trending down. - Quarterly detection tuning loop operating from IM-Endpoints post-incident and ST-Endpoints finding inputs; ≥1 net detection change per cycle. - ML-Endpoints logging-baseline validation element fresh (≤30 days) for all Critical-tier archetypes in PC-Endpoints compliance evidence bundles.

Level 3: - ≥90% of the detection set expressed as version-controlled, CI/CD-deployed artifacts; detection coverage auto-verified on SM-Endpoints inventory changes within 24 hours. - ≥90% of Critical/High-tier endpoint archetypes with anomaly detection active; anomaly models retrained monthly. - ≥2 telemetry-standard contributions per year to CSA Endpoint AI Safety Initiative or equivalent; ≥12 anonymized detection signatures per year to sector ISACs; OWASP MASVS contributions tracked and maintained.

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 disclosure-shown flag events 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; shadow-AI-in-SaaS goes undetected. - ❌ Edge-device boot-attestation events logged but not retained, the log pipeline drops attestation events after 7 days for storage cost reasons; a tamper event from last month cannot be reconstructed for an IR investigation. - ❌ Detection set grows without governance, new detections are added at each incident but none are ever retired; the team spends more time triaging false positives on stale detections than investigating real signals.

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; 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 gaps on the IM-Endpoints backlog? 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? 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?

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)? 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? 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?

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? 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? 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?

Document Version: HAIAMM v3.0 Practice: Monitoring & Logging (ML) Domain: Endpoints Last Updated: 2026-05-14 Author: Verifhai