Appearance
Fleet inventory and coverage
Last reviewed: October 24, 2026
Use this guide to plan AI inventory across separate hospitals, clinics, offices and networks. Briard can combine supported management inventories, approved device checks and supplementary activity signals. It cannot guarantee discovery of every AI tool, model or private account. The useful result is an inventory with evidence and visible gaps, measured against the devices your organization expects.
Availability in this edition
The expanded fleet inventory, device-name lookup, provider controls and Jira delivery paths are separately enabled features and are off by default. Source checks also depend on their individual activation, licensing, permissions and approved scope. The expanded workflows have not yet completed full real-provider, hosted customer-workflow or long-running fleet acceptance. This guide describes the conditional workflows; it does not establish that they are available or validated in your deployment. If a control is absent or says Not enabled, ask support about the approved rollout rather than assuming coverage.
Start with one of these tasks:
- Establish the devices and sites you expect.
- Connect and deploy approved checks.
- Review gaps and discovered AI.
Define a safe scope for each site
Create or select a Workplace for each approved operational boundary. A workplace is an assigned scope; it is not a geolocation service. Keep distinct organizations, clinical boundaries and restricted networks separate. Record which management accounts, devices and checks belong to each workplace, including remote laptops and approved exceptions.
Start with a small IT-approved cohort. For medical or other safety-critical equipment, obtain the responsible clinical, biomedical, security and equipment-owner approvals before installing a collector, accessing a device or changing connectivity. A vendor restriction or unsupported system remains a documented gap or expiring exception. An inventory request does not authorize a probe, model execution, endpoint isolation or a change to patient-care systems.
Use governance metadata only. Do not include patient information, clinical records, PHI, prompts, responses, document contents, credentials or secrets in labels, imports, tasks or evidence. The platform data boundary still applies.
Establish the expected device set
Open Shadow AI Discovery, choose Workplace above, then expand Device and model inventory. Inventory follows that selection. Change workplaces using the same selector; if the selected workplace is unavailable, choose an authorized workplace before continuing. Select Check fleet coverage > Expected devices. Use Workplaces in this assessment to select the sites you are authorized to compare.
An expected-device register answers “What should be checked?” It is separate from the devices that happened to report. Include devices with no known AI, remote and temporarily offline devices, and restricted equipment.
Where available, select a completed management roster and Review managed register. Choose the required checks, then confirm whether that source is both authoritative and complete for the selected workplace. Only select those statements when the organization has established them. A permission-limited Intune, Jamf or CrowdStrike account is not automatically the complete estate. Use Use and refresh this roster to approve the reviewed binding. Later complete checks can refresh it; failed or incomplete acquisition preserves the prior expected set.
To use an existing subset, open Choose a saved device group (optional) and select an Expected device group. Review its workplace, device count, operating systems and source date. This limits the expected register; it does not change the provider's access, collection scope or deployment group. A selected group does not establish the entire workplace's device count.
The preview shows matched, missing and ambiguous devices. Missing or ambiguous group members remain expected and are not counted as checked. If the group's register, membership, source approval or freshness changes, refresh the choices and review the group again. Briard preserves the earlier register while review is needed.
Alternatively, open Import a file from IT. Download an empty CSV or JSON template, or copy the request for your IT team. Copying prepares the request; it does not send it. The template and field guide use the selected workplace and explain the required opaque device references, operating-system and management-state categories, checks and source dates. Ask IT for an unknown source date rather than guessing.
Review the completed, approved reduced export using Review import, then Use this expected set. Approved provider aliases can link it to reported devices. Do not upload a raw asset file containing names, serial numbers, user details or network addresses. Previous versions remain available for review and restoration.
Keep source authority, freshness, identity conflicts, retirements and exception expirations current. A restored earlier register may require its automatic roster binding to be reviewed again. A retired device that continues reporting needs attention. An exception records an approved coverage limitation; it does not prove the omitted check ran or approve clinical use of AI.
If a site's complete, current expected set is unknown, Briard keeps Coverage percentage unknown. Unexpected reporting devices and unresolved identity conflicts can also prevent a reliable percentage. Do not replace an unknown denominator with the number of reporting devices.
Connect management and device checks
Use Connect the places AI can hide with the correct workplace selected. Review the exact account, permission and check before approving access. These paths answer different questions:
| Source or check | What it can establish within its approved scope | What remains unproved |
|---|---|---|
| Intune device roster | Devices visible to the approved management account, including devices with no matched AI app | Every device at the site; current app or model inventory |
| Intune app relationships, Jamf Pro or CrowdStrike software inventory | Supported recognized software associated with provider device records | Unreported software, every user profile, local model contents or execution |
| Defender software inventory | Supported software/device associations exposed by the licensed source | A complete model inventory; all software outside the provider's reporting support |
| Approved Ollama or LM Studio device check | Models visible through that device's selected loopback API, with available/loaded state where supported | Inference, a prompt, successful AI use or another user's inaccessible runtime |
| Approved model folders, software and extension folders | Recognized metadata within selected accessible roots | The rest of the disk, arbitrary renamed or embedded models, every browser profile |
| Approved nested environments | The exact selected WSL, container or package-environment scopes | Automatic enumeration of all guests, containers or developer environments |
Management software data can be delayed, filtered or permission-limited. Defender availability also depends on the licensed tables and retained data. Intune device synchronization time is kept separate from an unknown application inventory date. A new delivery to Briard does not make old provider data fresh.
Provider-local device references stay within that source unless a supported authoritative device identity or approved mapping establishes a match. Cloned identities, conflicting references and ambiguous re-enrollment remain unresolved. Do not merge devices by a shared user, hostname, IP address or similar label.
Capability prerequisites
These are prerequisites for the implemented collection paths, not a promise of availability on every licensed plan, operating system or device. Confirm the selected provider account's actual permission-visible records and your target environment before rollout. Provider inventory and a locally installed collector are separate sources.
| Capability | Required access or platform | Collection limit |
|---|---|---|
| Intune roster and detected apps | Active Intune tenant license; approved Organization.Read.All and DeviceManagementManagedDevices.Read.All; devices reported by Intune | Recognized apps and visible managed devices only. Device sync time is not application inventory age; unmanaged devices remain outside this source. |
| Jamf Pro application inventory | Jamf Pro API client with computer inventory read access and application inventory available for the selected Macs | Reported Mac software only; not all employee folders or local models. |
| CrowdStrike application inventory | Falcon Discover entitlement and the selected read-enabled API client; supported reporting sensors/devices | Applications visible to that account. An installed sensor alone does not establish application-table or all-OS coverage. |
| Defender software and network evidence | Approved Organization.Read.All and ThreatHunting.Read.All; the relevant licensed hunting tables, supported OS/sensor and device-group visibility | Software inventory and retained device contacts are different evidence. Table access does not grant device isolation or prove all devices were checked. |
| Windows / Linux / macOS machine collector | Administrator-managed Python 3.11+ and cryptography, independent publisher approval, per-device enrollment and local read permissions | Windows uses LocalService. Linux needs systemd encrypted credentials; native evidence is QA WSL. RC9 adds macOS system-job credential provisioning and explicit Keychain selection, with isolated macOS 15 ARM64 same-boot proof. Reboot, endurance, Intel Mac and management rollout acceptance remain open. See the deployment guide. |
| Ollama / LM Studio models | Selected literal loopback API on the enrolled device; supported model-list endpoints; approved local API token where required | Available/loaded metadata only; no model launch, download or inference. A stopped or inaccessible API leaves a gap. Runtime/model license rights remain the customer's responsibility. |
| Model-file metadata | Approved accessible roots containing GGUF v2/v3 or safetensors candidates | Fixed GGUF header or bounded safetensors JSON header. No model payload, full shard validation, authenticity proof or MLX on-disk weight inventory; MLX may appear as runtime API metadata. |
| Software, extensions and developer packages | Explicit accessible application, Python, Node, VS Code or Chromium-extension roots | Reviewed catalog matches and bounded metadata, not every package ecosystem, browser profile, browsing history or arbitrary configuration file. |
| WSL / local Docker / developer environments | Exact approved scopes; WSL already running; Docker local daemon and exact running container; approved non-root guest Python reader where needed | No automatic guest enumeration or arbitrary commands. Developer contexts stay attached to the parent host. A Windows service cannot automatically access per-user WSL; native Docker acceptance remains open. |
| Managed Browser Check | Approved Chrome/Edge extension identity, valid managed policy and allowed origins; visible disclosure and user-started collection | Supplementary browser-profile evidence. Force installation is not collection consent or host identity; actual store/MDM deployment requires separate acceptance. |
None of these checks reads prompts, responses or model weight payloads. Renamed, embedded, inaccessible or unsupported AI can remain unknown. Missing permission or unsupported scope must remain a coverage gap, not a clean-device result.
Assign a central source's network evidence to workplaces
When this fleet feature is enabled, open Assign central network evidence to workplaces under fleet coverage. Select the source workplace and each destination in the assessment. Choose a supported central source, then explicitly assign its provider device references to a workplace or a saved device group. These references are review identifiers; they are not device names or proof of physical location.
Review the source dates, selected and unassigned devices, destinations and expiry in the preview before Confirm future mapping. A changed source check or group requires another review. The current mapping path supports retained Defender device references. Cloudflare DNS and the current Splunk saved-search format do not provide the device authority this mapping requires.
The mapping applies to later complete source windows within its effective dates. Earlier windows, windows spanning a change, expired mappings and unresolved devices remain explicit gaps. History supports reviewed restoration when the source and group are still eligible. Routing a contact to a workplace does not expand collection permissions, establish complete device inventory, prove successful AI use or identify who performed an action. Original source receipts and blocked-contact meaning remain visible.
Deploy approved device checks centrally
For an available local inventory source, choose Microsoft Intune, Jamf or Linux configuration management. Choose the checks, review their scope, then select Approve inventory profile. This saves a profile for that workplace; it does not install the collector or grant access to all computers.
Begin with the local runtime checks you need. The collector reads the approved loopback API; it does not start that API, load a model or perform inference. Add model/software folder templates only when the exact user homes and permissions have been approved. A service account's home is not an employee's home. Host paths are entered in the local deployment configuration and are not sent as connection metadata to Briard.
Nested checks need exact local scopes. WSL distributions must already be running and accessible to the selected Windows identity; a machine service cannot automatically access an employee's per-user registration. Container access and its exact executable/socket need separate approval. The guided host configuration keeps those names, paths and command pins local. Missing permissions, stopped APIs and unavailable environments remain incomplete checks.
Machine installation is offered only when the approved distribution supplies a pinned package and valid publisher manifest/signature. A source archive, test ZIP or unsigned deployment recipe is insufficient. If signed distribution is unavailable, retain the profile and complete the administrator handoff; do not invent a signature or substitute a download.
IT assigns the cohort in its management platform and provisions protected, device-specific enrollment and privacy keys through its approved channel. Use the supplied deployment material for the selected operating system. Confirm installation, service readiness, actual acquisition and a received check separately. An enrolled or online service can still lack the required inventory evidence.
Expand from a reviewed pilot only after the intended environment passes installation, permissions, update, recovery and removal checks. Removing the service preserves retained data and does not automatically revoke remote credentials or erase keys. Coordinate revocation and retention separately. These instructions do not establish reboot, unattended operation or sustained fleet performance for your environment.
Signed collector pilot
Collector 0.1.0-rc.9 is a signed pilot candidate for approved administrator deployments. Use the package, release manifest and detached signature together. This is a Briard Ed25519 publisher signature; it is not a Windows Authenticode or Apple notarization claim.
Follow Deploy and maintain the device collector for independent trust verification, per-device credentials, Intune/Linux recipes, the limited macOS pilot, updates, rollback and removal. RC9 includes a fresh macOS credential provisioner for an approved root system job and explicit protected Keychain selection. Isolated same-boot proof does not establish reboot, sustained operation, Intel Mac compatibility or a customer management rollout. The guide is public; customer installation does not require access to Briard's private source repository.
Before installing, your administrator must independently confirm publisher briard-collector-2026-10 through an already established Briard support contact and approve the public pilot policy. Downloading a key or policy does not approve it. Provision the approved policy, bootstrap and interpreter through your existing management system; the package cannot establish its own trust.
| Verify independently | SHA-256 |
|---|---|
| Publisher public key, decoded 32-byte value | 5f2e02137da10294c586b26e6d0c9422b6efd5c6c77e404d02bdc9e7e3a1c070 |
| Exact pilot-policy file | 10f18372e6ac8ed3ff11ed7129ce23a3b2b23ed36ea4ac4b43bcb02b0857cc7b |
| Package ZIP | 8bd791f02fb422a278d464b6f2b9d4a8800e412d6c70ce007127bf02fedc1972 |
The revised policy preserves the RC7 and RC8 pins and adds this exact RC9 source release and sequence 2026101103 in the pilot ring. The manifest states its validity window; after expiry, obtain a newly approved release before a fresh installation. Existing verified installations retain their documented offline behavior. Do not change a sequence, pin or timestamp to bypass verification. Rollout to more devices requires a separate administrator decision and the checks above.
If installation fails, retain the fixed stage and code result for support. These identify the failed installation step without exposing credentials or raw host diagnostics. A successful signature check establishes package integrity and publisher authorization under your approved policy; it does not establish a completed device check, source coverage or supported unattended operation on every platform.
The original RC7/RC8 packages and their RC7 policy and RC8 policy remain unchanged. RC7 supports legacy profiles only; hardware matching requires RC8 or another explicitly compatible approved release. RC8 does not contain the new macOS provisioning path. Approving the revised policy does not change an existing profile or enrollment.
Match device records across sources
Optional hardware matching helps an administrator review whether supported observations refer to the same physical computer. It does not discover additional AI software or establish that every employee profile was checked.
In the local inventory profile, expand Match computers across inventory sources and explicitly select the hardware check before reviewing and approving the profile. It starts off. Deploy a compatible signed release to each approved computer. Raw make/serial fields stay on the endpoint; Briard receives reduced identity metadata. Missing access or rejected hardware values remain visible gaps.
After inventory arrives, open the connection's collector settings, expand Device matching, then choose Review device match and Read current review. Compare the opaque references with your deployment records. Approve only after verifying the device and every listed previous inactive collector. Choose I'm not sure to leave the records unmatched. Active duplicates, another site's claims and conflicting hardware must be resolved before approval.
Reported software remains visible while matching needs review. A later unavailable check, changed hardware, revoked enrollment or new conflict can remove clean identity coverage; old successful evidence does not make the current check complete.
When a matched device has retained original records, use Choose original device record in private-name lookup. Choose the exact reference and enter a fresh purpose before revealing a name. Workplace grants, fresh MFA, expiry and audit still apply; matching never transfers a private name automatically.
Read coverage and source age
Under Check fleet coverage > Coverage and gaps, inspect both the device summary and Checks and next steps for each required capability.
| Displayed state | Meaning and next step |
|---|---|
| Fully checked | Each required, non-exempt check has complete evidence within its freshness window for the approved scope. It does not mean every possible AI is known. |
| Partly checked | A required check is missing or incomplete, or its source age cannot be established. Open the capability details. |
| Out of date | Source evidence or its receipt is outside the permitted freshness window. Obtain a new completed check. |
| Offline | The applicable source or enrolled collector is offline; retained inventory may still exist. |
| Access unavailable | Approved scope or collection access is unavailable. Repair that access. |
| Never checked | No qualifying completed evidence is linked to that device and required check. |
| Device match needs review | Conflicting device references prevent a trustworthy match. Resolve identity before counting coverage. |
| Approved exception | An explicit, unexpired exception covers the required check. It is not successful collection. |
| Retired | The expected register marks the device retired. Investigate continued reporting. |
Read Source inventory and Received separately. Unknown source age remains unknown. A heartbeat or successful authentication cannot substitute for software or model acquisition. The headline percentage applies only to the selected workplaces and eligible expected devices; retired devices and devices whose checks are all exempt are excluded. For example, 450 fully checked out of 500 eligible expected devices is 90% for those required checks—not a claim that 90% of all AI is known.
Use Recheck approved sources for eligible managed checks. Queuing a check does not improve coverage until its evidence arrives. Installed collectors need their own schedule and repair. Scheduled checks and gap alerts can save recurring assessments when enabled; they do not grant new access or run an unauthorized device check. Save assessment and Saved reports preserve a dated comparison for review and export. An export is a snapshot, not a live assurance statement.
Inspect an application or model
Select Reported devices, then View device. Apps and models shows current reported instances, versions when available, evidence references and source ages. A device with no matching app remains a device record.
Installed, Available, Present, Loaded and Activity observed are different claims. A model can be present or loaded without being used. An unknown identity or version is not silently converted to a recognized product. A complete replacement inventory can retire earlier records only within that same source and scope; an incomplete check must not be treated as proof of removal.
Current discovery records are created and refreshed from accepted evidence without approving the software. My AI tools holds governed records with reviewed ownership, purpose, permitted data and policy decisions. A discovery match or group count does not create that approval. Use the finding's review and explicit Add to AI inventory action where offered, or open an existing governed AI record to complete the review.
Identify a device when authorized
Ordinary inventory uses protected references. Identify this device is a separate, audited lookup. It requires an explicit workplace grant, a fresh MFA check and a selected purpose. An owner or administrator must deliberately grant lookup access; their ordinary role is not an automatic reveal permission.
A lookup manager can maintain an approved, expiring device-name mapping and redact it. A reader can reveal an authorized current mapping; lookup managers can also review the audit history. This is a customer-maintained mapping, not a reverse lookup that discovers names or users. Use approved operational labels without patient or other prohibited data. Revealed names clear when the view closes, the site or identity changes, the tab is hidden or the short display timeout expires. They are not part of ordinary fleet exports.
Keep browser, network and cloud evidence separate
Open Browser, network and cloud evidence to review account/location scope, observation window, sampling and source status. A DNS request, network contact or blocked contact does not prove a successful AI request. A configured cloud resource does not prove device coverage. Browser Check is supplementary per-browser-profile discovery and has no host or physical-site identity.
An administrator may review an explicit asset association and its expiry. The association preserves the original evidence meaning; it does not turn a shared network subject, browser report or cloud resource into a fully checked endpoint. Continue to review disconnected accounts, personal devices, hidden APIs and unapproved services as gaps.
Assign review and follow-up
Select Review discovered AI or Review device policy. Open a product group to inspect the individual device/version records. Status can be Approved scope, Restricted, Prohibited, Documented exception, Exception expired or Needs review. Review the applicable policy version, scope and expiry. Changed policy, an unapproved governed record or a different software version can require a new review.
Select the records, choose Request policy review, Request an exception review or Assign follow-up, assign an owner and due date, then Create review tasks. A request for an exception does not approve one. Closing a task does not prove removal or remediation.
Send a Jira ticket only after review
When Jira delivery is enabled and the approved integration is configured, use Review Jira ticket for this record. Complete fresh MFA and the guided Atlassian approval for the intended site. Select an existing open review task, project and issue type. Preview Jira ticket shows the exact content and destination.
Explicitly acknowledge the project's notification rules, then Authorize this ticket. Send authorized ticket once is a separate action. Ticket content uses standard review wording and Briard references; do not add patient details or credentials. Check Jira receipt checks the saved issue; it does not verify the underlying remediation. If delivery is pending or unknown, inspect saved status and reconcile in Jira before creating another request. Briard does not automatically resend an uncertain request.
Review controls and a possible investigation handoff
Separately enabled controls require current evidence, an open task, fresh administrator MFA, separate action/verification credentials, and review of the exact target and impact. Discovery credentials do not authorize control. Defender isolation can disconnect the entire endpoint; a Gateway DNS rule affects traffic using its selected location. Either can disrupt care or other services. Use your organization's change authority and clinical safety process before approving an action.
Keep delivery, provider receipt and independent effect review distinct. Provider acceptance or a saved rule does not prove the desired effect. Record approved evidence of the exact target, action and observation time, retaining unknown, partial or failed outcomes when warranted. Expiring or revoking a control setup does not automatically undo a provider action.
Preview BARC handoff lets you review a reduced snapshot. Save pending case-link draft saves a pending review only: nothing is sent to Briard Alert & Response Console (BARC), no remote case is created and no event feed is enabled by that step. Continue through the existing handoff review and separately verify any eventual delivery and source coverage. Inventory evidence alone does not establish misuse, a data disclosure or clinical harm. See BARC source coverage.