Security Requirements (SR)

Endpoints Domain - HAIAMM v3.0

Practice Overview

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

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

Context: Without a shared requirements pack, each deployment review invents the acceptance bar from scratch. An AI assistant and a customer-facing chatbot receive inconsistent review. EU AI Act Art. 50 disclosure obligations, GDPR Art. 22 automated-decisioning safeguards, and deployer duties under Art. 26 are not consistently verified because there is no shared traceability from regulation to requirement to evidence artifact. SR-Endpoints closes that gap, not with a checklist of 60 items, but the requirements that matter for every endpoint AI the org deploys, plus archetype-specific additions for chatbots, mobile AI apps, edge devices, and browser extensions.

Maturity Level 1

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

At this level, the organization stops re-deriving requirements intake by intake and starts selecting, adapting, and evidencing from a shared pack that every practice inherits.

Dependencies

• TA-Endpoints L1 (required): requirements derive from the archetype threat library, without the threat library the pack is arbitrary rather than threat-driven.
• PC-Endpoints L1 (required): requirements inherit policy guardrails and the priority compliance map (EU AI Act Arts. 26, 50; GDPR Arts. 6, 9, 22, 28, 44–49; OWASP MASVS; sector obligations).
• SM-Endpoints L1 (required): the SM inventory scope and archetype taxonomy define which deployments the pack applies to and which archetype deltas are relevant.
• Supports / unblocks: SA-Endpoints L1 (reference patterns implement the requirements), DR-Endpoints L1 (design reviews check proposed deployments against the pack), IR-Endpoints L1 (implementation reviews verify the REM evidence is accurate), ST-Endpoints L1 (security tests target the requirements), IM-Endpoints L1 (findings route to the REM gap register).

Desired Outcomes

• A single AI/HAI Endpoints Requirements Pack exists; IT, endpoint engineering, and security reviewers select from it rather than drafting from scratch at each intake.
• Every endpoint AI deployment approved for the managed estate has a REM showing which pack requirements are met (by what evidence), which gaps are accepted (with a named owner and expiry date), and which compensating controls are in place.
• EU AI Act Art. 50 disclosure obligations, Art. 26 deployer duties, and GDPR Art. 22 automated-decisioning safeguards are traceable to specific pack requirements, not hand-waved in narrative.
• The pack is versioned, owned, and refreshed quarterly as threats (TA) and compliance expectations (PC) evolve.
• Downstream practices (SA, DR, IR, ST) inherit the REM rather than re-deriving requirements independently.
• Cross-Vendors-domain REM linkage is active: endpoint AI sourced from a vendor has a Vendors-domain REM for vendor-level controls; the Endpoints REM covers endpoint-local controls and cross-references the Vendors REM.

Activities

A) Author the base AI/HAI Endpoints Requirements Pack

The base pack applies to every endpoint AI deployment the org manages, regardless of archetype. Keep it short (target ≤20 base requirements at L1). Each requirement has: an ID, a statement, a rationale (threat tag from TA-Endpoints + compliance tag from PC-Endpoints), an evidence source, a test method, and an acceptance criterion.

Minimum base categories:

• Identity and auth: SSO + MFA on AI consoles and admin interfaces accessed from endpoint; managed-endpoint requirement for Critical-tier AI use (Critical-tier endpoint AI may only be accessed from managed, enrolled devices); personal-account prohibition for org data (org employees may not use personal accounts to access AI tools that process org data); service-principal model (not a shared credential) for any endpoint AI tool with backend access to org systems.
• DLP at endpoint: DLP controls configured at the endpoint or network layer to block or alert on regulated-data paste into AI assistants; DLP rules tuned for AI-specific patterns (code containing secrets, PHI structured data, customer record exports); DLP alerting scoped to AI provider domains for outbound egress monitoring.
• Browser extension allowlist and per-extension scope review: only allowlisted AI browser extensions may be installed on managed endpoints; each allowlisted extension has a documented scope review confirming: host-permission scope justified (no <all_urls> without documented necessity and compensating controls), page-content-read access justified, DOM-write access justified; extensions not on the allowlist are blocked at the MDM/browser-policy layer.
• Per-archetype data-class boundaries: documented declaration of which data classes may flow into each endpoint AI archetype; regulated data (PII, PHI, confidential source code, customer records) may not flow to an endpoint AI without a documented no-train assertion and a data processor agreement.
• Vendor no-train assertion verified at admin-console level: for any endpoint AI consuming org data, the vendor's no-train setting is confirmed at the admin-console or API level and re-verified on a documented cadence, not trusted from contract text alone; a failed re-verification routes to IM as a Critical finding.
• Endpoint logging: AI-tool use events logged (application launched, API call made, extension activated) with sufficient fidelity to support incident investigation; data exfiltration attempt alerts forwarded to SIEM; extension installs on managed endpoints logged and compared against the allowlist.
• Customer-facing AI disclosure (Art. 50): every customer-facing chatbot or conversational UI displays a persistent, accessible disclosure that the user is interacting with an AI system; disclosure cannot be suppressed by system prompt, user request, or UX flow; disclosure is present on every session start, not only on demand.
• Mobile permission scope minimization: mobile AI apps request only permissions necessary for the stated AI function; permissions are documented and justified in the REM; over-broad permissions (access to all contacts, background location, unrestricted sensor access) are blocked or require exception approval.
• Local-model integrity verification: for endpoint AI that uses an on-device model, model artifacts are signed and the signature is verified at load time; unsigned or unverifiable model artifacts are rejected.
• Edge device integrity: edge AI devices run only signed firmware and signed model artifacts; attestation at boot confirms firmware and model integrity; unsigned artifacts are rejected; physical-tamper detection is present where feasible.
• Kill-switch / disable path: every endpoint AI deployment has a documented disable path (admin console toggle, MDM policy push, network block) that can be invoked within 4 hours of a decision to disable; kill-switch is tested at least annually.
• Affected-persons rights surface (Art. 22): for endpoint AI deployments that drive or substantially contribute to decisions with legal or significant effect on individuals (access grants, content moderation decisions, credit or benefit determinations), a documented process exists for affected individuals to obtain human review, contest the decision, and receive an explanation, per GDPR Art. 22 and EU AI Act Art. 26 deployer duties.

Every base requirement is tagged to: at least one TA-Endpoints archetype threat and at least one item from the PC-Endpoints priority compliance map.

B) Author per-archetype requirement deltas

On top of the base pack, each archetype carries a short delta (typically 3–8 additional requirements) reflecting the threat-specific obligations from TA-Endpoints's archetype threat models.

Deltas to ship at L1:

• AI assistant / copilot on managed endpoint: no-train assertion verified at admin-console level and re-verified quarterly (base pack covers the general case; this delta specifies the cadence for the assistant use case); tool allowlist published for any assistant with local file-system, shell, or external-API tool access; tool-scope minimization documented per tool (file-read scoped to declared directories; no file-write without explicit policy); per-session memory bounds documented (what context persists, retention period); audit log of assistant actions on endpoint (tool invocations, files accessed, commands run) retained and exportable.
• Browser-based AI tool: per-extension scope review on file for every allowlisted AI extension (host permissions justified, page-content-read justified, DOM-write justified; <all_urls> prohibited without exception); DLP integration verified for AI browser extensions (extension traffic inspectable or proxied for regulated-data egress); SSO enforcement for extension backend (extension authenticates to its AI backend using the org's identity provider, not a personal account); extension version pinned or update-channel controlled.
• Chatbot / conversational UI: prompt-injection defense at input edge (input validation and sanitization policy documented; system prompt hardened against common jailbreak patterns); output filter deployed (content policy enforced on chatbot outputs before delivery to user; filter documented and tested); Art. 50 disclosure on every customer interaction (UX implementation reviewed and tested; disclosure persistent and not suppressible); escalation-to-human path documented and operational (user can request human handoff; handoff SLA defined); rate-limit and abuse-detection controls deployed; per-session memory bounds documented; full prompt/completion logging with PII redacted per GDPR Art. 5.
• Multi-modal AI interface: modality-specific input validation deployed (image content moderation, voice biometric anti-spoof, video deepfake detection where required by the deployment tier); output safety filters cover all modalities (not only text output); cross-modal consistency check for high-stakes decisions (multi-modal output is internally consistent before being used to drive a consequential decision); biometric data handling documented under GDPR Art. 9 with lawful basis on file.
• AI-augmented productivity (SaaS-AI on endpoint): SaaS-admin governance for AI-feature enablement (intake required before enabling any AI feature at the tenant level; enablement events logged in admin audit log); per-feature data-scope review (what data the AI feature can access is documented and reviewed before enablement); conditional enablement policy (Critical-tier roles or sensitive data scopes require specific review before AI feature is enabled; rank-and-file enablement by documented intake process); admin audit of who enabled what AI feature when is retained and exportable.
• Mobile AI app: signed app and signed local model (app binary integrity verified via app-store signing or MDM; on-device model signing verified at load time); permission audit on file for every deployed mobile AI app (permissions requested vs. permissions required by AI function; over-broad permissions blocked or exception-approved); on-device model integrity attestation (attestation result logged; failed attestation prevents model load); secure-enclave requirement for sensitive operations (biometric processing, credential handling by the AI app); opt-in for sensor access (access to camera, microphone, location, health data requires explicit user opt-in and a documented AI purpose).
• Edge AI device: signed firmware + signed model required (attestation at boot; unsigned artifacts rejected; attestation result logged); device attestation at boot confirmed (attestation chain available and verified by backend at first connect); physical-tamper detection documented and tested where feasible; uplink traffic signed and encrypted (model inference results and sensor streams sent over the uplink are authenticated and encrypted in transit); remote-disable mechanism tested at least annually.

C) Wire the pack into the SM intake gate, establish cross-Vendors-domain REM linkage, and produce a REM per deployment

Every endpoint AI deployment approved for the managed estate carries a REM. Structure:

• Each applicable pack requirement (base + archetype delta) marked: Met / Met-with-compensating-control / Gap-accepted / Not-applicable (with justification for N/A).
• Each Met row cites specific evidence: MDM policy screenshot, admin-console state, extension scope review artifact, DLP rule configuration, kill-switch test result, Art. 50 UX screenshot, model-signing verification log, or attestation record.
• Each Met-with-compensating-control row describes the control, its coverage, and its limitations.
• Each Gap-accepted row names a compensating control (if any), a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor.
• Cross-Vendors-domain REM linkage: for endpoint AI sourced from an external vendor, the Endpoints REM cross-references the Vendors-domain REM for that vendor; vendor-level controls (DPA, no-train contract clause, vendor security assessment) live in the Vendors REM; endpoint-local controls (DLP at endpoint, tool allowlist, admin-console verification) live in the Endpoints REM. A change in the Vendors REM (e.g., vendor DPA updated, no-train clause removed) triggers a flag on the corresponding Endpoints REM.
• REM is stored with the SM inventory record and linked from the intake ticket.

Material changes (new tool access granted, permission scope expanded, model swap, new user population, new data class accessible) trigger REM re-review before the change is approved.

Outcome Metrics (L1)

Process Metrics (leading)

• Pack review cadence, quarterly refresh recorded; changes change-logged.
• REM turnaround, median ≤3 business days from threat snapshot (TA) to REM completion.
• Reviewer consistency, calibration on sample REMs produces ≤2 row-level diffs across independent reviewers.
• Material-change trigger rate, % of endpoint AI changes that trigger a REM re-review vs. changes that proceed without triggering one (expected zero unreviewed material changes at L1).

Effectiveness Metrics (business value)

• Requirements reused vs. invented, ≥80% of REM rows reference the pack unchanged; the remainder are archetype adaptations; zero rows invented per-intake from scratch.
• Audit readiness, EU AI Act Art. 50 and Art. 26 deployer-duty inquiries answered via REM evidence without re-collection.
• Downstream reuse, SA, DR, IR, ST artifacts cite REM rows directly rather than re-deriving requirements independently.

Success Criteria

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

Maturity Level 2

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

At this level, every requirement in the pack is either measurable (with a specific SLA) or binary (with an explicit evidence condition). REM rows are validated against observed reality for Critical/High-tier deployments, attestation is never trusted without corroboration. Accepted-gap aging is managed per tier. The pack differentiates meaningfully across tiers. REM auto-revalidation is wired to MDM, SaaS-admin, and DLP telemetry signals. Pack updates from IR and IM findings flow back into requirements automatically.

Dependencies

• SR-Endpoints L1 (required): base pack, archetype deltas, and REM template must be established before quantitative refinement is meaningful.
• SM-Endpoints L2 (required): the risk-tier rubric (user population, data classes accessible, action capability, customer-data egress potential, deployment scale, regulatory scope, Art. 50 disclosure obligation) determines which deployments receive full per-tier treatment.
• TA-Endpoints L2 (required): per-deployment deep threat models inform per-deployment requirement adjustments for Critical-tier deployments.
• Supports / unblocks: SA-Endpoints L2, DR-Endpoints L2, IR-Endpoints L2 (each inherits the quantitative per-tier pack), ST-Endpoints L2 (tests validate pack SLAs directly).

Desired Outcomes

• Every requirement in the pack carries a specific, testable condition, a concrete SLA or a binary evidence condition, with all qualitative "appropriate" or "reasonable" language removed.
• REM rows for Critical and High-tier deployments are re-validated against observed reality at least quarterly (Critical) and semi-annually (High), not on attestation alone.
• Accepted-gap backlog aging is managed per tier: no Critical-tier gap stays open beyond 60 days without documented escalation to the program sponsor.
• Per-tier pack differentiation is visible and enforced: Critical-tier deployments get the full pack with executive sign-off; Low-tier deployments get the base pack with a fast-track REM process.
• REM auto-revalidation is wired to MDM telemetry, SaaS-admin audit logs, and DLP signals; pack updates from IR and IM findings are operationalized within a defined SLA.

Activities

A) Quantitative and binary requirement pack

For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions:

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

B) Per-tier requirement depth

Publish a per-tier pack overlay aligned to the SM L2 tier-treatment matrix:

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

C) REM auto-revalidation and pack updates from IR and IM

Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation wired to observable telemetry: - MDM/UEM telemetry, extension allowlist compliance confirmed; unauthorized app install alerts cross-checked against REM. - SaaS-admin audit logs, AI feature enablement events confirmed against REM (no unapproved feature enabled since last review). - DLP signals, regulated-data egress alerts to AI provider domains cross-checked; zero unresolved alerts in the REM evidence period. - Vendor admin-console API, no-train setting re-confirmed via API query (not only screenshot); result logged. - Model integrity attestation log, mobile and edge device attestation results pulled from the attestation service; zero unsigned-model loads confirmed.

Pack updates from IR and IM: every IM-Endpoints incident that touches a pack requirement triggers a REM row re-validation for the affected deployment and a pack update assessment within 14 days. IR findings that surface a missing requirement category trigger a pack amendment sprint within 30 days.

Validation deltas are routed to IM-Endpoints as findings with severity tags and remediation SLAs matching the deployment's tier.

Outcome Metrics (L2)

Process Metrics (leading)

• Pack change-log, ≥1 substantive update per quarter reflecting new TA threats or PC compliance updates.
• REM validation sampling calendar, no missed quarters for Critical; no missed semi-annual cycle for High.
• Accepted-gap escalation SLA met, no gap hits escalation threshold without prior notification to the named owner.
• IR/IM-to-SR feedback loop, % of IR findings that trigger a REM update for the affected requirement row.

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as REM evidence is pre-assembled rather than collected on demand.
• Art. 50 disclosure testing pass rate rises as chatbot and conversational UI deployments are validated against the binary disclosure condition rather than UX screenshots alone.
• Audit pass rate on AI-specific endpoint controls, external auditors find REM evidence sufficient without supplemental interviews.

Success Criteria

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days.
• Accepted-gap backlog inside aging targets per tier; no Critical-tier gap past 60 days without documented escalation.
• 100% of Critical-tier deployments carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM.
• Per-tier pack overlay published and enforced; SM intake routing verified.
• REM auto-revalidation wired to MDM, SaaS-admin, DLP, and attestation telemetry for Critical and High tiers.

Maturity Level 3

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

At this level, the requirements pack and REM become machine-processable. Endpoint AI deployments are attested at deploy or configuration time, a deployment that fails a Critical-tier REM requirement is blocked at the MDM policy gate or SaaS-admin gate, not caught weeks later at the next manual review. The pack is published as a referenceable artifact contributing to CSA endpoint AI security, OWASP MASVS AI extensions, and the NIST AI RMF Playbook reference pack ecosystem.

Dependencies

• SR-Endpoints L2 (required): quantitative pack and continuous validation must be mature before automation is trustworthy.
• PC-Endpoints L3 (required): compliance-evidence automation substrate (machine-readable attestation) is the substrate that SR L3 gates consume.
• ML-Endpoints L2+ (required): runtime signals (DLP coverage, attestation completeness, kill-switch test results) are the evidence sources that REM auto-validation reads.

Desired Outcomes

• An endpoint AI deployment fails the gate if a Critical-tier REM requirement is unmet, compliance is enforced at deploy time, not audited afterward.
• REM evidence is largely auto-validated; human review goes to novel clauses, edge-case N/A justifications, and accepted-gap escalations.
• The pack is referenced and adopted outside the organization, standards bodies cite it; peer organizations use the REM schema.
• The program contributes to the emerging vocabulary of machine-readable AI endpoint security requirements (CSA endpoint AI security, OWASP MASVS AI extensions, NIST AI RMF Playbook reference packs, ISO/IEC 27090 successor guidance).

Activities

A) Machine-readable pack and endpoint-attestation at deploy

Express the Requirements Pack (base + archetype deltas) in a structured schema (JSON or YAML) where each requirement has: an ID, a machine-readable evidence type (MDM-policy-check / admin-console-API / attestation-log-query / DLP-telemetry / manual-attestation), an acceptance predicate, and a tier applicability field.

At deployment or configuration time for Critical and High-tier endpoint AI: - Automated checks run against the deployment's REM: SSO + MFA confirmed via IdP API; extension allowlist compliance confirmed via MDM policy; no-train setting confirmed via vendor admin-console API; DLP rules active and current; kill-switch mechanism confirmed tested within defined age; model-signing attestation confirmed for mobile and edge deployments. - Checks that pass write a signed attestation to the REM record. - Checks that fail block the deployment for Critical-tier; emit a warning and auto-route a finding to IM-Endpoints for High-tier. - Manual-attestation rows (Art. 50 UX review, human-rights-surface documentation) are prompted for re-confirmation at deploy time if the deployment has changed since last manual review.

B) Automated REM-evidence validation from runtime signals

Subscribe the REM validation pipeline to: - MDM/UEM telemetry, extension allowlist violations, unauthorized app installs, policy-compliance state. - SaaS-admin audit logs, AI feature enablement events, admin-console state changes. - DLP signals, regulated-data egress alerts to AI provider domains. - Attestation service logs, mobile and edge device model-integrity and firmware-integrity attestation results. - IM-Endpoints incident records, post-incident reviews that touch a pack requirement trigger auto-flagging of relevant REM rows for re-validation. - SM inventory change events, a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth.

Human review reserved for: novel requirement types; Art. 50 UX review; accepted-gap escalations; Art. 22 affected-persons-rights surface documentation.

C) Standards contribution

Contribute to: - CSA endpoint AI security working group, machine-readable requirement schema for AI/HAI endpoint security; REM schema as an open artifact. - OWASP MASVS AI extensions, practitioner input on requirement categories and evidence conditions for mobile AI apps and AI-augmented productivity tools. - NIST AI RMF Playbook reference packs, submit practitioner commentary on MEASURE and MANAGE function requirement language grounded in Endpoints REM experience. - ISO/IEC 27090 / AI security standards successor work, submit concrete, testable AI endpoint security requirements as candidate clause language.

Target: minimum 2 substantive contributions per year; legally vetted and anonymized.

Outcome Metrics (L3)

Process Metrics (leading)

• Structured-schema coverage, % of requirements expressed in machine-readable form (target: growing toward 100% of Critical/High-tier requirements).
• Automation error-rate monitored, false-positive and false-negative gate failures tracked; threshold triggers human review.
• Contribution pipeline ≥2 in-flight at any given time.
• Pack published version freshness, public version aligned with internal version (no version lag exceeding one quarter).

Effectiveness Metrics (business value)

• Reduced time-to-deployment for compliant endpoint AI, the attestation gate replaces manual REM review cycles for the ≥70% of requirements with automated checks.
• Zero Critical-tier endpoint AI deployments with unmet REM requirements reaching the managed estate, the gate enforces what used to be a post-hoc audit.
• Industry recognition as a contributor to AI endpoint security requirements standards.

Success Criteria

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

Key Success Indicators

Level 1: - AI/HAI Endpoints Requirements Pack published: base set (≤20 requirements) plus seven per-archetype deltas (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), every requirement tagged to a TA-Endpoints archetype threat and a PC-Endpoints priority compliance item; reviewers selecting from the pack, not drafting per intake. - 100% of new endpoint AI deployments approved in the last 90 days have a completed REM on file, every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific evidence, each Gap-accepted row naming a compensating control, owner, and re-review date. - ≥90% of active endpoint AI deployments in the SM inventory carry a current-year REM; accepted-gap backlog median age inside ≤90 days. - EU AI Act Art. 50 disclosure obligations, Art. 26 deployer duties, and GDPR Art. 22 automated-decisioning safeguards are traceable to specific pack requirements in every applicable REM. - Cross-Vendors-domain REM cross-reference operating for Critical-tier endpoint AI sourced from external vendors; named pack owner and quarterly refresh cadence operating.

Level 2: - 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative "reasonable" and "appropriate" language removed. - ≥95% of Critical-tier REMs re-validated against observed reality (MDM telemetry, SaaS-admin audit log, DLP signals, vendor admin-console API, attestation service) in the last 90 days; validation deltas routed to IM-Endpoints. - No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor; no High-tier gap beyond 90 days. - 100% of Critical-tier deployments carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM, not vendor assertion alone.

Level 3: - Machine-readable Requirements Pack and REM schema published under permissive license with tracked adoption; ≥80% of Critical-tier requirements have endpoint-attestation at deploy time. - ≥70% of REM evidence rows auto-validated via MDM/UEM, SaaS-admin, DLP, and attestation telemetry; human review reserved for exceptions and novel clauses. - Zero Critical-tier endpoint AI deployments going live with a failing REM check; gate telemetry confirms enforcement. - ≥2 substantive standards contributions per year to CSA endpoint AI / OWASP MASVS / NIST AI RMF Playbook / ISO AI security standards successor work.

Common Pitfalls

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

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

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

Practice Maturity Questions

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

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

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

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Endpoints Last Updated: 2026-05-14 Author: Verifhai