Strategy & Metrics (SM)
Endpoints Domain - HAIAMM v3.5
Generated from the canonical cell records in
cells/. Do not edit by hand; editcells/SM-Endpoints-L*.cell.jsonand re-runtools/render.py.
Practice Overview
Business Function: Governance
Objective: Stand up endpoint AI assurance, inventory the AI reaching users on managed and unmanaged devices, and baseline the metrics that prove sideloaded and browser AI is shrinking.
Description: A program at this level knows what AI its people can reach from the devices they work on. The seven archetypes span assistants and copilots on managed endpoints, browser-based AI tools, chatbot and conversational interfaces, multi-modal interfaces, AI-augmented productivity features inside SaaS, mobile AI apps and edge AI devices. The domain's distinguishing difficulty is that most of the signal lives with IT rather than security, and much of the adoption happens in a browser where neither has visibility by default. Browser extension audit is the highest-yield control here, and seat utilisation doubles as both a waste metric and an exposure metric.
Maturity Level 1, Foundational
Objective: Stand up endpoint AI assurance, inventory the AI reaching users on managed and unmanaged devices, and baseline the metrics that prove sideloaded and browser AI is shrinking.
A program at this level knows what AI its people can reach from the devices they work on. The seven archetypes span assistants and copilots on managed endpoints, browser-based AI tools, chatbot and conversational interfaces, multi-modal interfaces, AI-augmented productivity features inside SaaS, mobile AI apps and edge AI devices. The domain's distinguishing difficulty is that most of the signal lives with IT rather than security, and much of the adoption happens in a browser where neither has visibility by default. Browser extension audit is the highest-yield control here, and seat utilisation doubles as both a waste metric and an exposure metric.
Dependencies
- Required: None.
- Alignment (not blocking): Endpoint management and identity programs, since the discovery signals are owned by IT and the inventory depends on their data; Software asset management for seat and licence data
- Supports / unblocks: PC-Endpoints-L1; TA-Endpoints-L1; EH-Endpoints-L1; ML-Endpoints-L1; IM-Endpoints-L1; EG-Endpoints-L1; Required by: DR-Endpoints-L1, IR-Endpoints-L1, SA-Endpoints-L1, SM-Endpoints-L2, SR-Endpoints-L1, ST-Endpoints-L1
Desired Outcomes
- Every AI capability reachable from a managed endpoint is inventoried against one of the seven archetypes and attributed to an owner.
- Browser-based AI tools and extensions are enumerated rather than assumed absent, since they leave no installation footprint.
- AI reaching corporate data from unmanaged devices is a known and quantified exposure rather than an unexamined one.
- Provisioned AI seats that nobody uses are visible, because they are simultaneously wasted spend and standing access.
- Users have a sanctioned endpoint AI option that is at least as convenient as the unsanctioned one.
Activities
A) Charter endpoint AI assurance jointly with IT
Publish a charter within the first 30 days sponsored by the CISO jointly with the IT or Digital Workplace leader, because in this domain the discovery data, the enforcement points and the user relationship all sit with IT, and a security-only program will be able to describe the problem without being able to act on it. Name the seven in-scope archetypes, being AI assistant or copilot on a managed endpoint, browser-based AI tool or extension, chatbot and conversational interface, multi-modal AI interface, AI-augmented productivity feature inside SaaS, mobile AI app, and edge AI device. Constitute the working group across Security, IT endpoint management, Identity, Data Governance, Privacy counsel and a representative of the user community. Define decision rights over which AI capabilities may be installed or enabled on a managed endpoint, who approves an exception, who can revoke access, and how unmanaged-device access to corporate data through AI tools is governed. Commit to a sanctioned option per archetype, because prohibition without provision reliably produces sideloading.
B) Inventory endpoint AI and audit the browser
Build one endpoint AI inventory recording per capability the archetype, the sanctioning status, the population with access, the data classes reachable through it, whether it is available on unmanaged devices, the identity and authentication path, seat count and utilisation, and links to the vendor inventory record where the capability is vendor-supplied. Seed from endpoint management and mobile device management, the identity provider application catalogue, and SaaS admin consoles. Then run the domain's highest-yield discovery mechanism: a browser extension audit across managed endpoints, enumerating installed extensions against a maintained list of AI-capable ones, because browser-resident AI installs without administrative rights, leaves no conventional software inventory footprint, and can read the contents of every page the user opens, including internal applications. Complement it with egress analysis to AI provider domains segmented by device management status, which is the only practical way to size the unmanaged-device exposure that the other signals cannot see.
C) Baseline the endpoint scoreboard and open the per-user ledger
Instrument and report quarterly: endpoint AI inventory coverage, the share of managed endpoints carrying only sanctioned AI capabilities, browser extension audit coverage and the count of unsanctioned AI-capable extensions in use, acceptable-use attestation across the workforce, estimated unmanaged-device AI exposure to corporate data, and known data-exposure events through endpoint AI. Open the per-user ledger recording AI consumption and seat cost per active user, with utilisation tracked beside cost. Seat utilisation carries double meaning in this domain and should be reported as both: an unused seat is wasted spend, and it is also a standing authenticated path from an identity to a vendor holding corporate data, which is exposure that persists precisely because nobody is looking at an unused account. Where seat and utilisation data sits with IT rather than security, record the dependency explicitly rather than estimating around it.
Outcome Metrics (L1)
| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| Endpoint AI inventory coverage against endpoint-management, identity and egress discovery | first discovery sweep | ≥85% within 12 months | Inventory reconciled against MDM, IdP catalogue and egress telemetry; where endpoints are unmanaged, a sampled survey with its coverage stated, recorded at E1 |
| Managed endpoints carrying only sanctioned AI capabilities | first endpoint sweep | ≥90% of managed endpoints | Endpoint management inventory joined to the sanctioned-capability list; where endpoints are unmanaged, a sampled survey with its coverage stated, recorded at E1 |
| Browser extension audit coverage across managed endpoints | first extension audit | ≥95% of managed endpoints audited at least monthly | Browser extension inventory from endpoint management; where endpoints are unmanaged, a sampled survey with its coverage stated, recorded at E1 |
| Unsanctioned AI-capable browser extensions in use | first extension audit result | 0 with access to internal applications, and falling overall | Extension inventory cross-referenced with the AI-capable extension list |
| Workforce with an acknowledged AI Acceptable Use Policy covering endpoint AI | first attestation run | ≥95% of workforce | HR / LMS attestation records |
Process Metrics (leading)
- Browser extension audit runs at least monthly across managed endpoints, with coverage published.
- AI-capable extension and provider-domain lists refreshed from community sources monthly.
- New endpoint AI capability requests triaged within 5 business days.
- Seat utilisation reviewed quarterly with IT, and unused seats deprovisioned within 30 days.
Effectiveness Metrics (business value)
- Time from user request to a sanctioned endpoint AI option falls, which is what prevents sideloading.
- Reclaimed licence waste from deprovisioned unused seats, reported quarterly.
- Documented cases where extension audit caught an AI tool with read access to internal applications.
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| AI consumption and seat cost per active user, by archetype | per active user | licence waste, where seats are provisioned and never used, which is simultaneously wasted spend and a standing authenticated path to a vendor holding corporate data | SaaS management platform joined to identity provider activity data |
| AI consumption per assisted action, by archetype | per assisted action | runaway per-user consumption from automation or abuse of a per-seat tool, which flat per-seat pricing hides until the vendor renegotiates | Endpoint AI gateway or vendor usage reporting joined to the inventory |
| Share of endpoint AI consumption attributable to a managed identity on a managed device | per dollar of endpoint AI consumption | AI consumption originating from unmanaged devices or shared accounts, where neither the data reaching the tool nor the person using it can be established | Identity provider and device-management posture joined to consumption records |
Level of Effort (incremental over the level below)
- Stand-up: 140 hours · Ongoing: 75 hours/quarter
- Program Manager / Practice Lead — primary, 24 days/year
- Security Analyst / SOC — regular, 14 days/year
- DevOps / Platform Engineer — regular, 10 days/year
- Legal / Privacy Counsel — low, 5 days/year
- Executive Sponsor — low, 3 days/year
- Material new tooling: Browser extension inventory and allowlisting through endpoint management, Egress telemetry segmented by device management status
Success Criteria
- A charter is published and jointly sponsored by the CISO and the IT or Digital Workplace leader, naming all seven archetypes and a sanctioned option per archetype.
- One endpoint AI inventory reaches 85% coverage or better within 12 months across MDM, identity and egress signals.
- Browser extension audit covers at least 95% of managed endpoints monthly, with zero unsanctioned AI-capable extensions holding access to internal applications.
- Unmanaged-device AI exposure to corporate data is quantified rather than assumed, with the estimate method documented.
- A per-user ledger is open recording seat cost and consumption per active user, with utilisation reported beside cost.
Maturity Level 2, Comprehensive
Objective: Tier endpoint AI by data reach and device posture, calibrate control intensity per tier, and bound per-user consumption on customer-facing and high-reach interfaces.
At this level endpoint controls follow what the AI can reach rather than where it happens to run. A published rubric derives a tier from data reachable through the capability, the population exposed, device management posture, whether the interface is customer-facing and whether untrusted content reaches it, and a treatment matrix states what each tier receives in allowlisting, authentication, data-loss prevention, logging and testing. Customer-facing conversational interfaces carry per-user and per-session consumption limits, because an endpoint that anyone can reach is the cheapest denial-of-wallet target in the estate and the one where abuse is indistinguishable from popularity.
Dependencies
- Required: SM-Endpoints-L1, PC-Endpoints-L1, TA-Endpoints-L1
- Alignment (not blocking): Endpoint management tiering and device compliance policy
- Supports / unblocks: PC-Endpoints-L2; TA-Endpoints-L2; SR-Endpoints-L2; SA-Endpoints-L2; DR-Endpoints-L2; IR-Endpoints-L2; ST-Endpoints-L2; EH-Endpoints-L2; IM-Endpoints-L2; ML-Endpoints-L2; Required by: EG-Endpoints-L2, SM-Endpoints-L3
Desired Outcomes
- Every endpoint AI capability carries a tier derived from data reach, exposed population, device posture, customer exposure and untrusted-content exposure.
- Allowlisting, authentication, data-loss prevention, logging and testing intensity are differentiated per tier and enforced.
- Customer-facing conversational interfaces operate under per-user and per-session consumption limits with declared behaviour at the limit.
- Access to high-tier endpoint AI from unmanaged devices is either blocked or explicitly accepted with a named owner.
- The scoreboard reports per tier, so a Critical-tier gap is not averaged away by a healthy managed-endpoint fleet.
Activities
A) Publish the endpoint AI risk-tier rubric
Derive four tiers from five auditable dimensions. Data reach is the floor: a capability that can read regulated or customer-confidential content, including a browser extension with access to internal application pages, sits at Critical or High regardless of how it was acquired. Exposed population elevates with the number of users and the breadth of their access, since a capability available to everyone inherits the union of everyone's reach. Device management posture elevates where the capability is reachable from unmanaged devices, because neither the endpoint state nor the data leaving it can be established there. Customer-facing exposure elevates to Critical for conversational and multi-modal interfaces reachable by the public, which combine untrusted input with an organizational voice. Untrusted-content exposure elevates where the capability processes content the organization does not control, which is the precondition for prompt injection to become action. Publish the rubric and re-derive when data reach or device posture changes.
B) Calibrate endpoint controls and consumption limits per tier
Publish a tier-treatment matrix covering per tier: extension and application allowlisting from advisory to enforced blocking; authentication strength and session policy; device compliance prerequisites including whether unmanaged access is permitted at all; data-loss prevention on input to the AI capability, which is the control most often omitted because it is harder than egress DLP; logging completeness including whether prompts and responses are captured and for how long; content filtering and output handling; testing obligations including prompt-injection batteries for anything processing untrusted content; and re-review triggers. Add the consumption row: customer-facing conversational and multi-modal interfaces carry per-user and per-session request and token limits with a declared behaviour at the limit, and per-user daily budgets for high-tier assistant capabilities. A public conversational interface is the cheapest denial-of-wallet target an organization operates, because the attacker needs no credentials and the abuse is indistinguishable from popularity until the invoice arrives.
C) Report per tier and govern unmanaged-device exposure
Report the scoreboard per tier and archetype quarterly covering inventory and tier state, allowlisting enforcement conformance, extension audit results per tier, per-tier logging completeness, consumption-limit conformance on customer-facing interfaces, seat utilisation per tier, and the Assured Spend Ratio for endpoint AI consumption. Produce an explicit unmanaged-device position, refreshed quarterly and signed by the sponsor, recording for each Critical- and High-tier capability whether unmanaged access is blocked, conditionally permitted with named compensating controls, or accepted as a risk with a named owner and a review date. This is the dimension most often left undecided in this domain, because blocking it is unpopular and permitting it is uncomfortable, so it persists as an unexamined default. Maintain a tier-movement log recording the triggering dimension and review it quarterly.
Outcome Metrics (L2)
| Metric | Baseline | L2 Target | Source |
|---|---|---|---|
| Endpoint AI capabilities carrying a current tier assignment | L1 inventory coverage | 100% of inventoried capabilities, with tier age under 12 months | Endpoint AI inventory tier field |
| Critical- and High-tier capabilities under enforced allowlisting rather than advisory policy | first allowlisting audit | 100% of Critical, ≥90% of High | Endpoint management allowlist enforcement configuration; where endpoints are unmanaged, a sampled survey with its coverage stated, recorded at E1 |
| Customer-facing conversational interfaces with per-user and per-session limits and tested at-limit behaviour | first limit audit | 100% | Gateway limit configuration reconciled against inventory tier; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1 |
| Critical-tier capabilities reachable from unmanaged devices without a signed acceptance | first unmanaged-access review | 0 | Device posture policy joined to the unmanaged-device position statement |
| Per-tier logging completeness against the tier's declared baseline | first logging audit | ≥95% at Critical and High | Logging configuration audit joined to inventory tier |
| Seat utilisation at Critical and High tier | L1 utilisation baseline | ≥80% of provisioned seats active in the last 30 days | SaaS management platform joined to identity provider activity; where none is in use, expense records reconciled against identity grants, recorded at E1 |
Process Metrics (leading)
- Tier re-derivation triggers on data-reach or device-posture change, and each run is logged.
- Allowlist enforcement verified continuously through endpoint management rather than sampled.
- Unmanaged-device position refreshed quarterly and signed by the sponsor.
- Consumption-limit configuration checked in the endpoint policy release process for every customer-facing interface change.
Effectiveness Metrics (business value)
- Unsanctioned AI-capable extensions fall toward zero as enforced allowlisting replaces advisory policy.
- Reclaimed licence waste from deprovisioned unused high-tier seats, reported quarterly.
- Documented cases where per-user limits contained abuse of a customer-facing interface before it became a budget event.
- Effort concentrates on Critical and High tiers relative to L1.
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| Consumption per active user at Critical and High tier against the tier's expected range | per active user | automation or credential sharing behind a per-seat tool, where one identity consumes at a rate no human could, which flat per-seat pricing conceals until renewal | Vendor usage reporting joined to identity provider activity and inventory tier |
| Consumption per session on customer-facing conversational interfaces | per session | denial-of-wallet against a public interface, where the attacker needs no credentials and the traffic is indistinguishable from popularity until the invoice arrives | Endpoint AI gateway session telemetry |
| Per-user limit breach rate and at-limit behaviour conformance | per interface-quarter | limits configured but silently continuing past the cap, which provides the appearance of a control with none of its effect | Gateway limit enforcement log |
| Seat cost per active user at Critical tier, with utilisation | per active user | unused high-tier seats persisting as both waste and standing authenticated access to the capabilities with the broadest data reach | SaaS management platform joined to identity provider activity |
Level of Effort (incremental over the level below)
- Stand-up: 150 hours · Ongoing: 100 hours/quarter
- Program Manager / Practice Lead — primary, 22 days/year
- Security Analyst / SOC — regular, 18 days/year
- DevOps / Platform Engineer — regular, 14 days/year
- Security Architect — low, 8 days/year
- Executive Sponsor — low, 3 days/year
- Material new tooling: Enforced extension and application allowlisting through endpoint management, Per-user and per-session limiting at the endpoint AI gateway
Success Criteria
- An endpoint AI tier rubric is published and applied to 100% of inventoried capabilities, re-derived on data-reach or device-posture change.
- A tier-treatment matrix is published covering allowlisting, authentication, device compliance, input data-loss prevention, logging, content filtering and testing.
- Every Critical-tier capability is under enforced rather than advisory allowlisting, and every customer-facing conversational interface carries tested per-user and per-session limits.
- No Critical-tier capability is reachable from unmanaged devices without a sponsor-signed acceptance naming an owner and a review date.
- A sponsor-signed unmanaged-device position is refreshed quarterly and a tier-movement log is reviewed with it.
Maturity Level 3, Industry-Leading
Objective: Drive endpoint AI discovery and tiering from continuous device and identity telemetry, benchmark per-user economics and exposure, and contribute endpoint AI assurance patterns back.
At this level the endpoint picture is continuous. Device management, identity, browser and gateway telemetry drive inventory and tier, so a newly installed AI extension or a newly enabled SaaS AI feature surfaces the same day rather than at the next audit. Per-user economics and exposure are benchmarked against peers, which is how an organization learns whether its endpoint AI footprint is normal or unusual for its size and sector. The program contributes extension-risk intelligence and endpoint AI hardening patterns back, which is unusually valuable here because the AI-capable extension list is a shared problem no single organization can maintain well alone.
Dependencies
- Required: SM-Endpoints-L2, ML-Endpoints-L2, EG-Endpoints-L2
- Alignment (not blocking): FinOps at Run maturity for per-seat and per-user cost attribution
- Supports / unblocks: Every other Endpoints-domain practice at L3, which inherits continuous discovery and tier data
Desired Outcomes
- A newly installed AI extension or newly enabled SaaS AI feature surfaces in the inventory the same day.
- Tier assignment updates automatically when a capability's data reach or device posture changes.
- Per-user economics and endpoint AI exposure are benchmarked against peers of comparable size and sector.
- The organization contributes extension-risk intelligence back, which no single organization can maintain well alone.
- Endpoint-domain return is computed from the per-user ledger and reconciled with Finance and IT.
Activities
A) Make endpoint AI discovery continuous
Replace periodic audits with streaming telemetry. Stream browser extension install and permission-change events from endpoint management, so an AI-capable extension acquiring read access to all sites raises an event rather than waiting for the monthly sweep; stream identity-provider first-authentication events against AI services; stream SaaS admin API change feeds for newly enabled AI features inside approved products; and stream endpoint AI gateway telemetry for previously unseen destinations. Wire tier derivation to re-run on data-reach and device-posture change and to open downstream obligations on tier increase. Publish a data-quality objective covering time from install or enablement to inventory record, targeting 24 hours, which is achievable here because the telemetry is event-driven rather than reconciliation-driven and necessary because a browser extension can read every page a user opens from the moment it is installed. Reserve human curation for capabilities on unmanaged devices, shared or service accounts, and genuinely novel archetypes.
B) Benchmark per-user economics and endpoint AI exposure
Publish a semi-annual brief comparing the program against peers of comparable size and sector on at least five metrics: endpoint AI inventory coverage and discovery latency, unsanctioned extension prevalence per thousand endpoints, seat utilisation by archetype, cost per active user by archetype, and unmanaged-device exposure share. Prevalence per thousand endpoints is the comparison that matters most and is rarely available, because it normalises for organization size and reveals whether an unsanctioned-extension count is a local failure or an industry baseline; an organization discovering forty unsanctioned AI extensions does not know whether that is alarming without knowing what comparable organizations find. Draw from peer security communities, sector information-sharing bodies, endpoint-management vendor user groups and the FinOps Foundation SaaS scope. Name the cohort, defend its selection, and publish where the program trails.
C) Contribute extension-risk intelligence and compute the endpoint return
Contribute at least four substantive artifacts per year, weighted toward the shared-maintenance problem: AI-capable browser extension risk classifications contributed to community lists, since no single organization can maintain this well alone and every organization currently tries; endpoint AI hardening baselines and allowlist configurations published in a form peers can apply; observed endpoint-layer techniques such as extension permission escalation and SaaS AI feature enablement without notification submitted to community advisories and MITRE ATLAS where they fit; and OWASP LLM working-group input on the endpoint attack surface. Count only externally accepted artifacts. Compute the endpoint-domain return from the per-user ledger: reclaimed licence waste from deprovisioned unused seats, which is usually the dominant component; contained per-user abuse and denial-of-wallet on customer-facing interfaces; and avoided exposure cost from extensions blocked before they gained access to internal applications, valued by the data reach they would have had. Reconcile with Finance and IT annually.
Outcome Metrics (L3)
| Metric | Baseline | L3 Target | Source |
|---|---|---|---|
| Time from extension install or SaaS AI feature enablement to an inventory record | L2 monthly audit interval | ≤24 hours at the 90th percentile | Endpoint and identity telemetry event pipeline |
| Endpoint AI inventory entries created without human curation | first quarter of automation telemetry | ≥80% auto-curated | Curation telemetry from the discovery pipeline |
| Unsanctioned AI-capable extension prevalence per thousand managed endpoints | L2 extension audit result normalised per thousand endpoints | at or below the peer cohort median, and falling | Extension telemetry normalised against managed endpoint count |
| Peer-comparable metrics in the semi-annual brief | 0 | ≥5 metrics with a named and defended peer cohort | Published benchmarking brief |
| Externally accepted endpoint AI assurance contributions per year | 0 | ≥4 accepted, weighted toward shared extension-risk classifications | Contribution log with external acceptance references |
Process Metrics (leading)
- Telemetry feed freshness and error rate monitored, with alerting on staleness breach.
- AI-capable extension classifications synchronised with community lists at least weekly.
- Tier re-derivation runs on every data-reach or device-posture change event.
- Contribution pipeline carries at least two artifacts in draft or external review.
Effectiveness Metrics (business value)
- Sponsor and IT decisions cite peer-normalised prevalence rather than raw counts, which are uninterpretable alone.
- Reclaimed licence waste from continuous utilisation review, reported quarterly.
- Computed endpoint return reconciles with Finance and IT annually without restatement.
- Peer adoption of contributed extension classifications and hardening baselines.
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| Cost per active user by archetype, benchmarked against peers of comparable size and sector | per active user | an endpoint AI footprint that is unusual for the organization's size and sector in either direction, which raw internal figures cannot reveal | Per-user ledger compared against the semi-annual benchmarking brief |
| Reclaimed licence waste from deprovisioned unused seats | per active seat recovered | seats accumulating through joiner-mover-leaver drift, carrying standing authenticated access to vendors holding corporate data | Deprovisioning records joined to the per-user ledger |
| Contained per-user and per-session abuse value on customer-facing interfaces | per contained event | denial-of-wallet against a public interface running long because the traffic looks like adoption, where time to detect is the whole of the loss | Gateway limit enforcement log joined to the per-user ledger |
Level of Effort (incremental over the level below)
- Stand-up: 180 hours · Ongoing: 70 hours/quarter
- Program Manager / Practice Lead — primary, 16 days/year
- Security Analyst / SOC — regular, 20 days/year
- DevOps / Platform Engineer — regular, 16 days/year
- Compliance / Audit — low, 4 days/year
- Executive Sponsor — low, 2 days/year
- Material new tooling: Streaming endpoint management telemetry for extension install and permission-change events, SaaS admin API change feeds for AI feature enablement
Success Criteria
- Discovery is continuous across extension, identity, SaaS admin and gateway telemetry, with install-to-inventory latency at or below 24 hours at the 90th percentile.
- At least 80% of inventory entries are auto-curated, with unmanaged-device and shared-account cases explicitly routed to human curation.
- Unsanctioned extension prevalence is reported per thousand managed endpoints and compared against a named peer cohort median.
- At least four externally accepted contributions per year, weighted toward shared AI-capable extension risk classifications.
- Endpoint-domain return is computed from per-user ledger arithmetic and reconciled with Finance and IT annually.
Key Success Indicators
Level 1:
- A charter is published and jointly sponsored by the CISO and the IT or Digital Workplace leader, naming all seven archetypes and a sanctioned option per archetype.
- One endpoint AI inventory reaches 85% coverage or better within 12 months across MDM, identity and egress signals.
- Browser extension audit covers at least 95% of managed endpoints monthly, with zero unsanctioned AI-capable extensions holding access to internal applications.
- Unmanaged-device AI exposure to corporate data is quantified rather than assumed, with the estimate method documented.
- A per-user ledger is open recording seat cost and consumption per active user, with utilisation reported beside cost.
Level 2:
- An endpoint AI tier rubric is published and applied to 100% of inventoried capabilities, re-derived on data-reach or device-posture change.
- A tier-treatment matrix is published covering allowlisting, authentication, device compliance, input data-loss prevention, logging, content filtering and testing.
- Every Critical-tier capability is under enforced rather than advisory allowlisting, and every customer-facing conversational interface carries tested per-user and per-session limits.
- No Critical-tier capability is reachable from unmanaged devices without a sponsor-signed acceptance naming an owner and a review date.
- A sponsor-signed unmanaged-device position is refreshed quarterly and a tier-movement log is reviewed with it.
Level 3:
- Discovery is continuous across extension, identity, SaaS admin and gateway telemetry, with install-to-inventory latency at or below 24 hours at the 90th percentile.
- At least 80% of inventory entries are auto-curated, with unmanaged-device and shared-account cases explicitly routed to human curation.
- Unsanctioned extension prevalence is reported per thousand managed endpoints and compared against a named peer cohort median.
- At least four externally accepted contributions per year, weighted toward shared AI-capable extension risk classifications.
- Endpoint-domain return is computed from per-user ledger arithmetic and reconciled with Finance and IT annually.
Common Pitfalls
Level 1:
- ❌ Relying on software inventory alone, which misses browser-resident AI entirely because extensions install without administrative rights and leave no conventional footprint.
- ❌ Prohibiting consumer AI tools without providing a sanctioned equivalent, which reliably moves the activity to personal devices where there is no visibility at all.
- ❌ Treating seat utilisation as a finance metric, which discards its second meaning as standing authenticated access nobody is watching.
- ❌ Running the program without IT as a co-sponsor, leaving it able to describe the exposure but not to act on it.
- ❌ Maintaining the AI-capable extension list by hand, so it decays and the highest-yield control in the domain quietly stops finding anything.
Level 2:
- ❌ Tiering by where the capability runs rather than by what it can reach, which under-rates a browser extension with read access to every internal page.
- ❌ Applying data-loss prevention to egress but not to input, so what users paste into the AI capability is never inspected.
- ❌ Publishing an allowlist as advisory policy, which produces a document and no change in what is installed.
- ❌ Leaving unmanaged-device access as an undecided default because blocking is unpopular and permitting is uncomfortable.
- ❌ Rate-limiting a public conversational interface by request count without a token or spend limit, which stops floods but not expensive-generation abuse.
Level 3:
- ❌ Streaming install events while ignoring permission-change events, which misses the extension that was benign when installed and later requested read access to all sites.
- ❌ Reporting raw unsanctioned extension counts, which are uninterpretable without normalising per thousand endpoints and comparing against peers.
- ❌ Consuming community extension classifications without contributing, which leaves the shared list that the whole control depends on chronically incomplete.
- ❌ Claiming auto-curation coverage that silently excludes unmanaged devices and shared accounts, which are the hardest and most exposed cases.
- ❌ Valuing avoided exposure from blocked extensions without reference to the data those extensions could actually have reached, which produces a number nobody believes.
Practice Maturity Questions
Level 1:
- Is there a published endpoint AI assurance charter jointly sponsored by the CISO and the IT or Digital Workplace leader, naming all seven archetypes, decision rights over installation and revocation, and a sanctioned option per archetype so that prohibition is paired with provision?
- Does one endpoint AI inventory reconcile against endpoint management, identity provider catalogues, SaaS admin consoles and egress telemetry, with a browser extension audit covering at least 95% of managed endpoints monthly against a maintained AI-capable extension list?
- Is unmanaged-device AI exposure to corporate data quantified with a documented method, and is a per-user ledger open recording seat cost and consumption per active user with utilisation reported as both a waste and an exposure measure?
Level 2:
- Is every endpoint AI capability assigned a tier from a published rubric covering data reach, exposed population, device management posture, customer-facing exposure and untrusted-content exposure, re-derived when data reach or device posture changes?
- Does the tier-treatment matrix cover allowlisting enforcement, authentication, device compliance prerequisites, input data-loss prevention, logging completeness, content filtering and testing, with 100% of Critical-tier capabilities under enforced rather than advisory allowlisting?
- Do all customer-facing conversational interfaces carry per-user and per-session limits with tested at-limit behaviour, and is there a sponsor-signed quarterly position recording whether unmanaged-device access to each Critical-tier capability is blocked, conditionally permitted or accepted?
Level 3:
- Is endpoint AI discovery continuous across extension install and permission-change events, identity first-authentication events, SaaS admin change feeds and gateway telemetry, with install-to-inventory latency at or below 24 hours at the 90th percentile and at least 80% auto-curation?
- Does the semi-annual benchmarking brief report unsanctioned extension prevalence per thousand managed endpoints and cost per active user by archetype against a named peer cohort of comparable size and sector, with the selection defended?
- Does the program contribute at least four externally accepted artifacts per year weighted toward shared AI-capable extension risk classifications, and is the endpoint return computed from per-user ledger arithmetic covering reclaimed waste, contained abuse and avoided exposure?
Lightweight Questions (E0 rung)
Answerable yes/no by one person in under 30 seconds, with nothing open.
Level 1:
- Do you know which AI browser extensions your staff have installed?
- Is there a sanctioned AI assistant people can use without asking?
- Are you paying for AI seats that nobody signed into this month?
Level 2:
- Does every endpoint AI capability carry a risk tier?
- Is your AI extension policy enforced, or is it advice?
- Can one user run up an unlimited bill on your public chatbot?
Level 3:
- Would a new AI browser extension show up in your inventory today?
- Do you know how your unsanctioned extension count compares per thousand endpoints?
- Have you contributed an AI extension risk classification to a community list?
Tracking
Level 1 — Jira Epic, labels haiamm-sm-endpoints-l1, haiamm-governance
- Done when: Endpoint AI inventory coverage at or above 85% with monthly extension audit covering at least 95% of managed endpoints and zero unsanctioned AI extensions holding internal application access, sustained two quarters.
- Git artifacts:
endpoints/ai-endpoint-inventory.json,endpoints/ai-capable-extensions.json,governance/endpoint-ai-charter.md,finops/per-user-ledger.json - Git signal: ai-capable-extensions.json is refreshed from community sources monthly rather than hand-maintained, and the extension audit job writes its coverage result on every run.
- CI check:
browser-extension-audit
Level 2 — Jira Epic, labels haiamm-sm-endpoints-l2, haiamm-governance
- Done when: Endpoint AI tier coverage at 100% with every Critical-tier capability under enforced allowlisting and every customer-facing interface carrying a tested per-user limit, sustained across two quarters.
- Git artifacts:
endpoints/tier-rubric.md,endpoints/tier-treatment-matrix.md,endpoints/allowlist-policy.yaml,gateway/endpoint-limit-config.yaml,governance/unmanaged-device-position.md - Git signal: allowlist-policy.yaml is applied by endpoint management in enforcing mode rather than audit mode, and unmanaged-device-position.md carries a sponsor signature block with a commit each quarter.
- CI check:
endpoint-allowlist-enforcement
Level 3 — Jira Epic, labels haiamm-sm-endpoints-l3, haiamm-governance
- Done when: Install-to-inventory latency at or below 24 hours at the 90th percentile with auto-curation at or above 80%, sustained two quarters, and unsanctioned extension prevalence at or below the peer cohort median.
- Git artifacts:
endpoints/discovery-pipeline/,endpoints/ai-capable-extensions.json,governance/benchmarking-brief.md,governance/contribution-log.json,finops/endpoint-return.json - Git signal: ai-capable-extensions.json is synchronised from community sources weekly and records the organization's own contributed classifications, and endpoint-return.json is regenerated from ledger data.
- CI check:
endpoint-discovery-latency
Mappings
| Level | HAI TTP | ATLAS | OWASP LLM 2025 | Compliance |
|---|---|---|---|---|
| L1 | AGH | AML.T0051 | LLM01, LLM02 | EU AI Act Art. 26; EU AI Act Art. 50; GDPR Art. 32; ISO/IEC 27001 A.5.9; ISO/IEC 27001 A.8.1; ISO/IEC 42001 8.1; NIST AI RMF MAP 1.1 |
| L2 | AGH, TM | AML.T0029, AML.T0051, AML.T0053 | LLM01, LLM02, LLM10 | EU AI Act Art. 26; EU AI Act Art. 50; GDPR Art. 32; ISO/IEC 27001 A.5.9; ISO/IEC 27001 A.8.1; ISO/IEC 42001 8.1 |
| L3 | AGH, TM | AML.T0029, AML.T0051, AML.T0053 | LLM01, LLM02, LLM10 | EU AI Act Art. 50; EU AI Act Art. 72; GDPR Art. 32; ISO/IEC 27001 A.5.9; ISO/IEC 27001 A.8.1; ISO/IEC 42001 9.1 |
Document Version: HAIAMM v3.5 (generated) / Practice: Strategy & Metrics (SM) / Domain: Endpoints
✓ Interactive Self-Assessment
Answer each question based on your current, implemented practices only. Progress saves automatically in your browser.