Privacy and data collection
This page is written to be forwarded. It is the complete list of what the client collects, and the list is deliberately short.
What the client collects
Why the device identifiers are plaintext
The serial, model, and account names are reported as they are on the machine rather than hashed, and they exist for one job: identifying a device that nobody has signed in on yet. An unattributed device shows up in your fleet list with no employee attached to it, and a hashed serial gives an admin nothing to match it against. A raw serial joins cleanly to the record your MDM already holds, and the model and the account names narrow it down when the MDM record is missing.
This does not widen who a device can claim to be. Identity is still resolved on Merge’s side, and the enrollment request carries no employee email or user id, so a device cannot assert an identity by reporting one. The account names are names, not credentials, and the list is capped so an unauthenticated enrollment cannot use it as a write channel.
What the client never collects
There is no configuration that turns any of these on, because the code to do them does not exist.
- No network traffic at all. The client reads configuration files on disk and reports what it finds. It does not observe connections, so there is nothing to intercept: it never terminates or decrypts a connection and never holds session keys
- No request or response bodies. No prompts, no completions, no file contents, no uploads
- No secret values. When the client finds a plaintext credential in an MCP config it reports that one exists and in which file. The value stays on the device
- No screen recording, screenshots, or keystroke logging
- No browser history, page contents, or form data
- No productivity scoring, idle-time tracking, or activity timelines
This is a deliberate trade. Vendors that report which account an employee used on a shared AI site do it by reading inside the session, through a browser extension or an inspecting proxy. The client does not do that, so it cannot tell you whether someone signed in to ChatGPT with a personal or corporate account. That is the cost of the guarantees above, stated here as a limit rather than blurred.
Identity and tool access
Identity is resolved by Merge, from the employee’s own one-time sign-in in the menu bar, which your identity provider authenticates. Two silent tiers, a token for the signed-in OS user and the device-to-user assignment read from your MDM, are on the roadmap; the sign-in is what resolves identity today. In every case the client has no configuration key, file, or setting that sets identity, so no employee, including one with local administrator rights, can present as a colleague. Governed AI usage is attributed by the Gateway key at Gateway rather than by the endpoint, so attribution does not depend on trusting the machine.
Tool access is granted by the organization from the employee’s synced Groups, without an individual consent prompt, so that a managed device is usable on day one. Employees can see exactly which tools are connected for them, and what data the client collects about them, in the menu bar panel. If your jurisdiction expects individual notice before an employer connects third-party tools on someone’s behalf, include the employee FAQ in your rollout communication.
What employees can see
Employees open the tray icon and see their own collected data. You choose which of five sections the panel shows, organization-wide, on Devices → Desktop client preview:
Usage and the colleague comparison are off by default for different reasons: a chart of zeroes reads as “you have used no AI this week” rather than as an empty state, and ranking colleagues by AI use is a choice an organization makes rather than a default it discovers. Nothing is shown to an employee that is not also reported to you.
Where you deploy in a jurisdiction with works-council or employee-notification requirements, showing the AI apps and MCP servers sections is what supports a transparency obligation: they are the two that name what the client found on that person’s machine.
Aggregation defaults
Usage reporting rolls up to the organization and Group level by default. Per-employee detail is available to dashboard members with the permission to view it, and every access to per-employee data is recorded in the audit trail.
Retention and residency
- Retention. Inventory is current-state, not a history: each report replaces the last, so uninstalled software leaves the record rather than accumulating in it. The device record and its inventory are removed when a device deregisters
- Residency follows the
TelemetryRegionconfiguration key,usoreu. Set it in your MDM at deployment time. Data written under one region is not replicated to the other - Deregistration removes the device record and its inventory. Usage rollups are retained to the end of the retention window, then deleted
Network destinations
The client talks to one host, the Agent Handler API for your region, over HTTPS on port 443. It opens no listening network ports. Local communication between the background service and the tray app uses a Unix domain socket on macOS and a named pipe on Windows, both restricted to the signed-in user.
Integrity properties worth telling your security team
- Both packages are signed with Merge’s certificates; the macOS package is also notarized by Apple
- Policy and catalog documents are Ed25519-signed by Merge and verified on the device before they are applied, so a network attacker cannot disable enforcement or redirect provisioning. The client has no code path that accepts an unsigned one. Production signing keys do not exist yet, so Merge serves no policy or catalog at all today and the client runs from the catalog embedded in its build
- Every artifact the client installs is verified against a hash carried in that signed policy document before it runs. The software catalog cannot be used to run arbitrary code on your fleet
- On macOS, the client subscribes to process events in notify-only mode. It cannot delay or veto a process launch, so it cannot deadlock the machine
- The device credential is issued by Merge at enrollment, 32 bytes of entropy, and only its hash is stored. The client keeps its copy in the macOS Keychain or the Windows TPM. It authenticates one machine under its own
Authorization: Devicescheme, carries no user identity, and is rejected by any endpoint expecting a user or organization key - Identity is never read from the endpoint, so no file edit can make one employee present as another. The serial is stored as an organization-salted hash and is what identifies a device across enrollments; a second enrollment on an existing serial drops the device’s attribution rather than inheriting it, so a reassigned laptop starts unattributed
- On a machine where the employee holds local administrator rights, no user-mode software can be tamper-proof. The client is built so that identity cannot be forged and tampering cannot be hidden: it heartbeats every five minutes, a device silent for 30 minutes shows as not reporting in the fleet view, and your MDM reinstalls it