Secure Architecture (SA)

Endpoints Domain - HAIAMM v3.0

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, DLP and egress controls, logging, controls mapped to SR requirements, and threats mitigated (tagged to HAI TTPs and MITRE ATLAS). The catalog is accompanied by an anti-pattern list derived from real incidents. 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. At L3, patterns are published as open artifacts contributing to CSA endpoint AI security, OWASP MASVS, and the ATLAS mitigation library.

Context: Without reference patterns, every team deploying an AI assistant, enabling a SaaS-AI feature, or launching a customer chatbot 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 threat models that discover problems too late, 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

At this level, architecture becomes prescriptive rather than advisory. Reference patterns are named, versioned, and the first thing a team reaches for when deploying an AI assistant, enabling a SaaS-AI feature, launching a customer chatbot, deploying a mobile AI app, or installing an edge AI device.

Dependencies

• SR-Endpoints L1 (required): patterns implement the base + archetype requirement packs; without the pack, pattern controls are stylistic choices rather than requirement-backed decisions.
• TA-Endpoints L1 (required): threat library drives which controls appear in each pattern and which threats each pattern claims to mitigate.
• PC-Endpoints L1 (required): patterns operationalize AI Acceptable Use and Data-Handling policy constraints for endpoint AI.
• SM-Endpoints L1 (required): inventory shows which archetypes the org actually deploys; patterns are authored for that archetype list.
• Supports / unblocks: DR-Endpoints L1 (design reviews use the pattern as the baseline), IR-Endpoints L1 (implementation reviews check pattern adherence), EH-Endpoints L1 (hardening targets the pattern's surface areas), ST-Endpoints L1 (security tests target the pattern's controls).

Desired Outcomes

• Every team deploying an endpoint AI finds a documented reference pattern within one click of the SM inventory record.
• Each pattern is concrete enough to implement: deployment topology, data-boundary definition, identity model, DLP / egress controls, logging points, controls with SR traceability, and named threats mitigated.
• Known anti-patterns, the architectural mistakes that have produced real incidents across the industry and inside the org, are named, explained, and linked to the reference pattern that replaces them.
• Deviations from reference patterns are visible and reviewed, not accidental or silent.
• Architecture decisions carry explicit traceability to SR requirements and TA threats.

Activities

A) Publish reference architectures per endpoint AI archetype

Publish one pattern per archetype the org actually deploys. Each pattern is concise (≤3 pages), includes a labeled deployment diagram, and covers the same structural elements.

Pattern skeleton (every archetype): - Scope, what the pattern covers and what it explicitly does not. - Data boundary, what data classes may reach the endpoint AI; what is blocked or redacted; DLP / egress control placement. - Identity and auth, SSO + MFA enforcement; managed-endpoint requirement; personal-account prohibition; service-principal model for backend access. - Deployment topology, how the endpoint AI is provisioned (MDM policy, SaaS admin console, app store deployment, firmware update channel); control points for enable/disable. - Logging, what events are captured (AI tool use, extension activation, data egress attempts, model integrity checks, admin actions); retention; export mechanism. - Controls mapped to SR requirements, explicit row-by-row mapping; gaps acknowledged. - Threats mitigated, which TA-Endpoints archetype threats the pattern addresses, which remain residual; HAI TTP tags (EA / AGH / TM / RA); MITRE ATLAS mitigation IDs where applicable.

Archetype reference patterns:

AI assistant on endpoint pattern. Managed-endpoint required: AI assistant tools may only be used on enrolled, managed devices (MDM policy enforced; personal device use blocked or risk-accepted with compensating controls). SSO + MFA to AI provider: authentication to the AI assistant's backend uses the org's identity provider; no personal accounts; MFA enforced. DLP-tuned egress: endpoint DLP rules configured to detect and alert on regulated-data patterns (source code containing secrets, customer records, PHI) in traffic to AI provider domains; high-confidence matches blocked; lower-confidence matches alerted and logged. Vendor no-train flag enforced: admin-console setting confirming no-train status confirmed and re-verified quarterly; vendor API called with no-training header where available. Tool allowlist for assistants with local tools: only tools on the published allowlist may be invoked; per-tool scope minimization documented (file-read scoped to declared directories; no file-write without explicit policy); tool-call logging with full invocation record. Per-session memory bounds: session context documented (what persists, retention period, cross-session sharing policy). Audit log of assistant actions on endpoint: tool invocations, files accessed, commands run, retained and exportable for IR use. Threats mitigated: confidential-data egress to vendor (DLP + no-train enforcement); prompt injection via opened files (tool allowlist + scope minimization); AGH via tool-using assistant (tool allowlist + per-session memory bounds); TM via assistant invoking endpoint tools (tool-call logging + allowlist). HAI-TTP: EA, AGH, TM. ATLAS: TA0011 Exfiltration mitigated by DLP; TA0007 Privilege Escalation mitigated by tool-scope minimization; TA0006 Persistence mitigated by per-session memory bounds.

Browser extension pattern. Extension allowlist: only extensions on the published allowlist are permitted on managed endpoints; allowlist enforced via MDM browser policy; unauthorized extensions blocked. Per-extension scope review: each allowlisted extension has a completed scope review confirming host-permission scope justified (no <all_urls> without documented necessity), page-content-read access justified, DOM-write access justified; scope review artifact stored in the SM inventory record. DLP integration for extensions: extension traffic is proxied or inspected for regulated-data egress where technically feasible; DLP rules applied to extension-to-backend traffic. SSO to extension backend: extension authenticates to its AI backend using the org's identity provider, not a personal account; personal-account use blocked by policy. Extension version control: extension versions pinned in the MDM browser policy; auto-update to unreviewed versions blocked. Threats mitigated: extension permission abuse (allowlist + scope review); DOM injection via AI extension (DOM-write permission justified + scope minimization); data egress via extension (DLP integration + SSO enforcement); AGH via tainted page content (policy limits extension scope). HAI-TTP: EA, AGH, TM. ATLAS: TA0009 Discovery mitigated by scope review; TA0010 Collection mitigated by DLP integration; TA0011 Exfiltration mitigated by SSO enforcement and DLP.

Chatbot pattern. Prompt-injection defense at input edge: input validation policy documented; user input sanitized before reaching the model context; system prompt hardened against known jailbreak patterns; system prompt not disclosed to users or extractable via inference attacks. Output filter: content policy enforced on chatbot outputs before delivery; output filter configured for the deployment's domain (customer service, HR, financial) and tested against known jailbreak and data-exfiltration probe types. Art. 50 disclosure on every customer interaction: persistent disclosure component present on every session start; disclosure text meets EU AI Act Art. 50 specificity; disclosure cannot be suppressed by system prompt, user request, or UX flow, verified via red-team probe. Escalation-to-human path: user can request human handoff at any point; handoff SLA defined and monitored; handoff event logged. Rate-limit + abuse-detection: per-user and per-session rate limits enforced; anomalous usage patterns (systematic prompt injection probing, data extraction patterns) trigger alert and throttle. Per-session memory bounds: session context scoped; cross-session data access blocked unless explicit design decision with privacy review. Full prompt/completion logging with PII redacted: all prompt and completion events logged; PII in logs redacted at log-write time per GDPR Art. 5. Threats mitigated: prompt injection (input validation + system prompt hardening); jailbreak (output filter + rate-limit); data exfiltration via crafted prompts (per-session isolation + output filter); Art. 50 suppression (persistent disclosure + red-team probe); brand-impact prompts (output filter + abuse-detection). HAI-TTP: AGH. ATLAS: AML.T0051 mitigated by input validation; TA0008 Defense Evasion mitigated by output filter; TA0014 Impact mitigated by abuse-detection and escalation.

Multi-modal pattern. Modality-specific input validation: image inputs pass through content moderation (explicit content, adversarial pattern detection); voice inputs pass through biometric anti-spoof (replay attack detection, deepfake voice detection where required by tier); video inputs screened for deepfake indicators where required. Output safety filters cover all modalities: not only text, image generation, audio synthesis, and video outputs are subject to content policy before delivery. Cross-modal consistency check for high-stakes decisions: where a multi-modal output drives a consequential decision (access grant, fraud determination, medical assessment), outputs from multiple modalities are cross-checked for consistency before being used. Biometric data handling: biometric inputs (face, voice, retina) handled under GDPR Art. 9 special-category conditions; lawful basis on file; retention and purpose-limitation documented; consent obtained where required. Threats mitigated: image / voice prompt injection (modality-specific input validation); steganographic payloads (image content moderation); deepfake-content acceptance (anti-spoof + deepfake detection); biometric-input abuse (GDPR Art. 9 controls). HAI-TTP: AGH. ATLAS: TA0008 Defense Evasion mitigated by modality-specific input validation; TA0040 ML Attack Staging mitigated by anti-spoof controls.

AI-augmented productivity pattern. SaaS-admin governance for AI-feature enablement: no AI feature may be enabled at the tenant level without a completed intake review; feature enablement events are logged in the SaaS admin audit log; the intake record is linked to the SM inventory record. Per-feature data-scope review: for each AI feature, the data it can access is documented and reviewed before enablement; features with access to regulated data (HR records, financial data, customer PII) require Privacy/Legal sign-off. Conditional enablement: Critical-tier roles or sensitive data scopes require specific review before AI feature is enabled; rank-and-file enablement follows the documented intake process; emergency-disable procedure documented and tested. Admin audit of who enabled what when: admin audit log retained and exportable; AI feature enablement and disablement events with actor identity and timestamp available for IR use. Vendor no-train verification: SaaS-AI vendor's no-train setting confirmed at the admin-console level and re-verified quarterly; failed re-verification routes to IM. Threats mitigated: silent feature-enablement (SaaS-admin governance + admin audit); data scope inheritance (per-feature data-scope review + conditional enablement); regulated-data flow into vendor model (no-train verification + DLP). HAI-TTP: EA. ATLAS: TA0006 Privilege Escalation mitigated by conditional enablement; TA0011 Exfiltration mitigated by no-train verification and DLP.

Mobile AI pattern. Signed app + signed local model: app binary integrity verified via app-store signing or MDM; on-device model binary signing verified at load time; unsigned or unverifiable model artifacts rejected; attestation result logged. Permission minimization: the app's declared permissions are reviewed and justified against the AI function; over-broad permissions (access to all contacts, background location, unrestricted sensor access) are blocked or require exception approval before the app is added to the MDM app catalog. On-device model integrity attestation: attestation result available to the backend; failed attestation generates an alert routed to ML-Endpoints within 5 minutes. Secure-enclave for sensitive operations: biometric processing, credential handling by the AI app, and sensitive model inference are scoped to the device's secure enclave where technically feasible. Opt-in for sensor access: camera, microphone, location, and health data access requires explicit user opt-in; purpose of each sensor access documented in the app's privacy disclosure. Threats mitigated: local-model integrity (app signing + model attestation); over-broad permissions (permission minimization policy + MDM catalog review); mobile-specific exfiltration vectors (attestation + secure-enclave scoping); biometric / MFA bypass (attestation + anti-spoof controls from multi-modal pattern). HAI-TTP: RA, EA. ATLAS: TA0005 Persistence mitigated by model-signing verification; TA0010 Collection mitigated by permission minimization; TA0007 Privilege Escalation mitigated by secure-enclave scoping.

Edge AI pattern. Signed firmware + signed model: edge device firmware and AI model artifacts are signed by an authorized key; signature is verified at boot; unsigned artifacts rejected; attestation result transmitted to backend at every boot. Device attestation at boot: attestation chain available and verified by the backend on first connect and after every reboot; device not trusted for inference until attestation succeeds. Physical-tamper detection: tamper-evident hardware controls (sealed enclosure, tamper-detection circuit) present where feasible; tamper events logged and alerted. Uplink signed + encrypted: model inference results and sensor streams sent over the uplink are authenticated (message signing or mTLS) and encrypted in transit; man-in-the-middle interception mitigated. Remote-disable: a documented remote-disable mechanism exists and can halt the device's AI functions within 4 hours of decision; remote-disable tested at least annually. Threats mitigated: on-device model integrity (firmware/model signing + attestation); physical-access attacks (tamper detection + enclosure controls); sensor-input injection (input validation + attestation chain confirming model integrity); uplink data exfiltration (signing + encryption on uplink). HAI-TTP: RA, AGH. ATLAS: TA0005 Persistence mitigated by firmware/model signing; TA0010 Collection mitigated by tamper detection; TA0011 Exfiltration mitigated by uplink encryption and authentication.

B) Publish the anti-pattern catalog

Name, describe, and prohibit the endpoint AI architectural patterns that reliably produce incidents. Each anti-pattern entry includes: description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it.

L1 anti-pattern set:

• AI assistant on unmanaged endpoint, an AI assistant with tool access to local files and API access to org systems is used on a personal, unmanaged device; MDM controls are absent; DLP is absent; the device is lost or compromised and the assistant's access tokens and conversation history are exposed. Replaced by: AI assistant on endpoint pattern managed-endpoint requirement and SSO enforcement.
• Browser extension with <all_urls> permission and AI backend, an AI browser extension with unrestricted host permissions reads session cookies, form fields (including passwords), and full page DOM across every site the user visits; data is sent to an unapproved AI vendor backend. Replaced by: browser extension pattern extension allowlist + per-extension scope review prohibiting <all_urls> without documented necessity.
• Chatbot without Art. 50 disclosure, a customer-facing chatbot is deployed without a persistent AI-interaction disclosure; users are not informed they are interacting with an AI system; violates EU AI Act Art. 50; creates regulatory and reputational exposure. Replaced by: chatbot pattern Art. 50 disclosure on every customer interaction.
• Multi-modal without input validation, a multi-modal AI interface accepts image uploads and audio inputs without content moderation or anti-spoof; attacker embeds prompt-injection instructions in an image or injects commands via audio; the model follows the injected instructions. Replaced by: multi-modal pattern modality-specific input validation.
• SaaS-AI feature enabled tenant-wide without intake, an admin enables a SaaS-AI productivity feature (e.g., Copilot, Notion AI) at the tenant level without a security intake; the AI feature inherits access to all shared drives, emails, and project channels including regulated data; no no-train assertion is verified. Replaced by: AI-augmented productivity pattern SaaS-admin governance requiring intake before enablement.
• Mobile AI with broad permissions, a mobile AI app is deployed via MDM with unrestricted access to contacts, location, camera, and microphone; the permissions far exceed the stated AI function; sensor data is processed by the AI backend and logged without retention limits or purpose limitation. Replaced by: mobile AI pattern permission minimization and opt-in for sensor access.
• Edge AI without firmware/model signing, an edge AI device runs unsigned firmware and an unsigned AI model artifact; an attacker with physical access replaces the model binary; the device thereafter produces attacker-desired outputs (access grants false sensor readings) with no detection. Replaced by: edge AI pattern signed firmware + signed model + attestation at boot.
• No-train assertion trusted from contract text, the org deploys an endpoint AI consuming org data and trusts the vendor's contractual no-train assertion without verifying the admin-console setting; the admin console has training on customer data enabled; regulated data trains the vendor's model. Replaced by: all archetypes' no-train verification requirement, admin-console-level verification with recurrent re-verification.
• Endpoint AI with no kill-switch, an endpoint AI tool is deployed without a documented disable path; a security incident occurs requiring immediate cessation of the tool's operation; the org cannot halt the tool promptly because no disable mechanism was designed or tested. Replaced by: base pack kill-switch requirement and per-archetype disable path.
• Chatbot with no escalation-to-human path, a customer-facing chatbot handles sensitive inquiries (complaints, disputes, health questions) with no capability for the user to reach a human; the chatbot produces harmful or incorrect advice with no safety net; affected individuals have no recourse 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

Reference patterns are only useful if teams encounter them at the right moment, when they are proposing a new endpoint AI deployment or expanding an existing one.

• 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 are a signal to update the pattern, not to keep approving exceptions.
• New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1)

Process Metrics (leading)

• Pattern review cadence, quarterly refresh with change-log maintained.
• New-archetype lead time, new pattern published within 30 days of the first intake in a new archetype category.
• Deviation-review SLA, ≤5 business days from deviation request to decision.
• Anti-pattern catalog linked from the AI Acceptable Use Policy and the SM intake gate.

Effectiveness Metrics (business value)

• Deployment lead time, time-to-production for a team deploying a new endpoint AI via the reference pattern (should decrease after patterns land and the green path is clear).
• Avoided-incident stories, documented cases where the pattern (e.g., extension scope review, chatbot output filter, edge device attestation) blocked or contained a real risk before deployment.
• Pattern reuse rate, % of new deployments using the pattern unchanged vs. deviating; rising reuse indicates the pattern is fit for purpose.

Success Criteria

• Seven reference patterns published, each with: labeled deployment diagram, scope declaration, data-boundary definition, identity and auth model, DLP / egress controls, logging spec, and row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats with HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs.
• Anti-pattern catalog published (minimum 10 entries), linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 BD SLA.
• ≥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; encode patterns as MDM configuration profiles and SaaS-admin baselines; update the anti-pattern catalog from IM-Endpoints incidents

At this level, architecture moves from "single-path reference" to "production-scale reference set." Tier-conditional patterns apply: Critical-tier deployments receive the full pattern with per-tenant isolation, sector-specific data-residency variants, and kill-switch configuration; High-tier deployments receive monitoring and logging MDM module baselines; patterns are encoded as MDM configuration profiles and SaaS-admin configuration baselines so teams apply rather than handcraft. The anti-pattern catalog evolves from real IM-Endpoints findings.

Dependencies

• SA-Endpoints L1 (required): base reference patterns and anti-pattern catalog are the substrate L2 extends.
• SR-Endpoints L2 (required): quantitative and tier-calibrated requirements drive the L2 pattern controls.
• TA-Endpoints L2 (required): per-deployment and per-tier deep threat models surface the controls each L2 pattern must cover.
• SM-Endpoints L2 (required): risk-tier rubric determines which tier-conditional pattern variant applies to each deployment.
• IM-Endpoints L1+ (required): incidents feed anti-pattern additions and drive pattern evolution.

Desired Outcomes

• Teams deploying Critical or High-tier endpoint AI have a production-grade pattern to apply rather than a napkin sketch to interpret.
• Tier-conditional pattern variants are explicit: Critical gets per-tenant isolation baselines, sector-specific regulatory overlays, and kill-switch MDM configuration; High gets monitoring and logging MDM / SaaS-admin modules; Medium and Low follow the base pattern.
• Anti-pattern catalog reflects real incidents from IM-Endpoints, not only theoretical harms.
• Pattern drift is detectable: MDM configuration profiles and SaaS-admin baselines enable conformance checking; deployments using hand-modified configurations are flagged.
• Architecture evidence for Critical-tier deployments is sufficient to support EU AI Act Art. 26 deployer duties, Art. 50 disclosure testing, and sector regulatory expectations.

Activities

A) Tier-conditional pattern extensions

Publish extended pattern variants calibrated to SM L2's tier-treatment matrix:

• Critical-tier overlay (applies to any archetype at Critical tier): 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, 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; Art. 50 disclosure testing requirement (red-team probe confirming disclosure cannot be suppressed by any known jailbreak technique, not only UX screenshot).
• High-tier overlay: monitoring and logging MDM / SaaS-admin modules included in the applied baseline (pre-wired AI-tool-use event logging, DLP alert routing, extension install telemetry, admin-audit log forwarding to SIEM); standard ML-Endpoints L2 detections pre-configured.
• Multi-region / cross-border pattern: 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; transfer mechanism selection step included as a required decision gate in the pattern).
• Managed-endpoint enforcement pattern: MDM enrollment verification before any Critical-tier endpoint AI is accessible (conditional access policy: enrollment confirmed by IdP / MDM before access is granted to AI assistant or SaaS-AI feature); BYOD risk-accept process with compensating controls documented.

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); 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 version-pinned; profile updates trigger a drift-detection pass against all enrolled deployments.
• Profile change log maintained; teams consuming a profile are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh

• Every IM-Endpoints incident classified to an anti-pattern (existing or new); classification recorded in the IM finding.
• Catalog refreshed monthly from IM-Endpoints findings; new anti-patterns surfaced to teams at intake time.
• 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)

Process Metrics (leading)

• Pattern refresh cadence, at least one substantive pattern change per quarter, change-logged.
• Anti-pattern review cadence, monthly from IM-Endpoints findings.
• MDM / SaaS-admin profile health monitored, profile-update notification and drift-detection pass tracked.
• Tier-treatment matrix adherence check, quarterly reconciliation of Critical/High deployment list against encoded-pattern adoption.

Effectiveness Metrics (business value)

• Deployment time-to-production drops for teams deploying Critical/High-tier endpoint AI that apply MDM profiles and admin baselines rather than handcrafting configuration.
• Incident rate on profile-encoded deployments lower than on hand-crafted configurations, tracked as a rolling 12-month comparison.
• Conformance check failures caught before production, not in DR or IR.

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

At this level, the reference patterns are open artifacts that the industry adopts, forks, and builds on. The org contributes pattern-derived mitigations to MITRE ATLAS (AML.M00xx), to OWASP MASVS AI extensions and Browser-Extension Security Top 10, to OpenSSF AI, and to the CSA endpoint AI security initiative. Pattern adoption telemetry is operational. Regulatory engagement on EU AI Act Art. 50 implementing guidance and sector endpoint AI architecture standards is active.

Dependencies

• SA-Endpoints L2 (required): MDM-encoded patterns and conformance checks are the substrate L3 publishes and maintains externally.
• SM-Endpoints L3 (alignment): automation and benchmarking substrate supports telemetry and benchmarking activities at L3.
• IM-Endpoints L2+ (required): incident-to-pattern feedback loop must be operational before incident data drives external contributions.

Desired Outcomes

• At least two SA-Endpoints reference patterns are cited or forked by recognized industry bodies (OWASP, CSA, MITRE ATLAS, sector equivalents).
• MITRE ATLAS mitigation library carries at least two AML.M00xx entries attributable to SA-Endpoints patterns (extension scope minimization, chatbot output filter placement, edge device attestation, endpoint DLP controls, or equivalent).
• Internal practice is aligned to the published external version, not an aspirational document the org once published and no longer follows.
• Regulatory bodies and sector organizations reference SA-Endpoints patterns in endpoint AI architecture guidance or implementing-act consultations.

Activities

A) Publish reference patterns as open artifacts

• Patterns published under Apache 2.0 or equivalent open license via OWASP MASVS, CSA endpoint AI security initiative, OpenSSF AI, or equivalent; sector-specific variants via relevant sector bodies (FS-ISAC, H-ISAC).
• Maintained upstream in the public repository; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks.
• Pattern adoption telemetry tracked: 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 aligned 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 (DLP at endpoint, no-train enforcement, uplink signing and encryption), TA0005 Persistence (firmware / model signing, per-session memory bounds).
• Target: at least two AML.M00xx entries proposed or validated per year; contributions 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

• Active participation 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 / MANAGE.
• Contribute to OWASP MASVS AI extensions, mobile AI app pattern as input to MASVS mobile AI security controls.
• Sector-specific: 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.

Outcome Metrics (L3)

Process Metrics (leading)

• External contribution pipeline, ≥2 pattern items in-flight (draft, in-review, or in-publication) at all times.
• Internal-external alignment audit, quarterly diff between internal pattern versions and published external versions; unexplained divergence queued for resolution.
• ATLAS contribution cadence, at least one contribution or validation per 6 months.
• Regulatory engagement calendar maintained with active items and target timelines.

Effectiveness Metrics (business value)

• Industry recognition, invitations to working groups, citations in published standards, peer adoption of SA-Endpoints patterns.
• Regulatory benefit, SA-Endpoints patterns referenced in implementing-act or guidance documents reduce Art. 50 and Art. 26 compliance uncertainty for the org and the industry.
• Talent, external publication and standards participation attracts experienced endpoint AI security architects.
• Faster sanctioned deployment, industry adoption of patterns means external teams the org integrates with arrive already familiar with the endpoint AI architecture norms; integration friction decreases.

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 / TA0005.
• Internal practice 100% aligned to the published external version, no unexplained internal deviations; all deviations proposed as upstream contributions.
• At least one documented regulatory or standards-body reference to SA-Endpoints patterns in implementing-act, guidance, or standards text.

Key Success Indicators

Level 1: - 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, scope, data-boundary definition, identity model, DLP / egress controls, logging spec, and row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats; HAI TTP tags (EA / AGH / TM / RA) and MITRE ATLAS mitigation IDs present where applicable. - Anti-pattern catalog published (minimum 10 entries), each linked to a reference pattern element that replaces it; linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training. - ≥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 verified by ST-Endpoints test, not only UX screenshot. - Deviation-review path operational with a named architect-reviewer population, ≤5 BD SLA, and a repeat-deviation signal that queues pattern updates.

Level 2: - 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 deployments running on encoded patterns. - 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; drift-detection operational. - 100% of Critical-tier deployments with EU AI Act Art. 26 and Art. 50 controls explicitly mapped in the pattern documentation.

Level 3: - ≥5 reference patterns published as open artifacts under a recognized open license; ≥2 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 Privilege Escalation, TA0008 Defense Evasion, TA0011 Exfiltration, TA0005 Persistence. - Internal practice 100% aligned to published external versions; all deviations proposed as upstream contributions, none silently forked. - At least one documented reference to SA-Endpoints patterns in a regulatory implementing-act, sector guidance document, or published 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 nobody aggregates the pattern-update trigger. - ❌ The AI assistant pattern describes SSO + 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. - ❌ Pattern controls are mapped to SR requirements in the document but the mapping is never validated against an actual deployed configuration, the traceability 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. - ❌ 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. - ❌ Pattern-drift detection fires on low-signal configuration noise; the team ignores it within a month; meaningful drift goes undetected.

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

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

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

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Endpoints Last Updated: 2026-05-14 Author: Verifhai