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

Category	Fields	Module
Device	hostname, OS version, platform, client version, hardware serial (hashed), MDM source	always
Employee identity	the employee resolved from your IdP token or your MDM’s device assignment, and which of those resolved it	always
Installed AI software	application name, version, install path, last-used timestamp	shadow AI logging
IDE AI extensions and CLI agents	extension or package identifier, version, last-used timestamp	shadow AI logging
MCP servers	server name, config file path, a hash of the launch command, and whether a plaintext secret is present in the file	shadow AI logging
AI web usage	five-minute rollups of process name, destination hostname, request count, bytes sent, bytes received	shadow AI logging
Provisioning state	which governed components are installed, their versions, and whether configuration matches policy	software provisioning
Enforcement events	which config file drifted, what was reverted or blocked, and when	enforcement modules

What the client never collects

These are architectural properties, not settings

There is no configuration that turns any of these on, because the code to do them does not exist.

No TLS interception. The client never terminates or decrypts a connection and never holds session keys. It sees the destination and the process that opened the connection, the same information your firewall sees
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 a token issued by your identity provider or from the device-to-user assignment in your MDM. 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

When the menu bar module is set to panel, employees open the tray icon and see their own collected data: the AI tools the client found on their machine, their own usage rollups, and which governed models and tools they have access to. Nothing is shown to them that is not also reported to you, and nothing is reported to you that they cannot see.

Admins choose whether the panel exists. Setting the module to silent means the client runs with no visible presence at all. Where you deploy in a jurisdiction with works-council or employee-notification requirements, panel is the setting that supports a transparency obligation; silent does not.

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 is set per organization on the shadow AI logging module, with a default of 90 days. Inventory records are current-state and are removed when a device deregisters
Residency follows the TelemetryRegion configuration key, us or eu. 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 documents are signed by Merge and verified on the device before they are applied, so a network attacker cannot disable enforcement or redirect provisioning
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 Windows, the client’s network filters are created in a dynamic Windows Filtering Platform session, so if the service stops for any reason the operating system removes every filter it added. The failure mode is that enforcement stops, never that the network breaks
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 a keypair generated in the Secure Enclave on macOS or the TPM on Windows. The private key is non-exportable, so a device credential cannot be copied to another machine even by a local administrator
Identity is never read from the endpoint, so no file edit can make one employee present as another. A device claiming another machine’s serial number does not inherit its identity, and a second enrollment on an existing serial raises an alert
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, your MDM reinstalls it, and after a 14-day offline grace window it fails closed

Next steps

Employee FAQ

A version of this page written for employees to read

Plan your deployment

Prerequisites, identity, and staged rollout