Workforce desktop client overview
The Merge Workforce desktop client is a small background service you deploy to employee laptops through your MDM. It reports which AI tools employees are using so you can see your whole AI footprint in one place, provisions each employee’s Gateway key and approved tools once their identity resolves, and will keep the governed stack (Gateway and the Merge MCP server) installed and current on the device once policy signing ships.
It runs on macOS 13 and later and Windows 10 21H2 and later. It requires an MDM-managed fleet: several of the macOS permissions it needs can only be granted by a configuration profile, so it is not supported on unmanaged or BYOD devices.
The Devices nav item is enabled per organization, and reading it needs View security alerts or Manage security alerts. Minting and revoking enrollment tokens needs Manage security alerts. If you do not see Devices under Manage in the sidebar, ask your Merge contact to turn it on.
The client is one of two ways to get employees onto Merge Gateway. The other is self-setup, which needs no MDM at all and is the only way to get any Cursor traffic routing. Choose a rollout path compares them before you commit to this one.
Modules
The client is a discovery sensor, an employee-facing panel, and a provisioning agent. Each part is configured organization-wide, on Devices in the Workforce console. There is no per-Group configuration.
Discovery and employee provisioning need no configuration and cannot be turned off. Software provisioning is the one enforcement decision, and it has two modes:
- Observe reports what is on each device and changes nothing. This is the default
- Enforce installs Gateway and the Merge MCP server, and reinstalls them if removed
Start in observe mode.
Enforcement travels in an Ed25519-signed policy document, and production signing keys do not exist yet, so the client has no policy to act on. Picking Enforce records your choice and the settings page says so; nothing is written to a device until signing lands. Until then, use your MDM to make the governed path mandatory: see Choose a rollout path.
Blocking the ungoverned network path is a separate, network-level capability that has not shipped. The macOS configuration profile pre-approves the content filter it will need, so the profile you deploy now does not have to change when it does.
What it collects
The client reports metadata, not content. Specifically, it collects:
- Installed AI applications, IDE AI extensions, and CLI agents, with the version and the risk band the catalog assigns each one
- MCP servers found in harness configuration files, with the harness each was found in, whether the server is governed, whether the config file is readable by other accounts on the machine, and whether it is synced to a file-sync service
- Whether a plaintext credential is present in an MCP config file, and its location, kind, and shape. The secret value is never transmitted
- A count of installed software the catalog did not recognize
It does not watch network traffic, intercept TLS, read request or response bodies, capture prompts, record the screen, or log keystrokes. Those are properties of how the client is built, not settings you have to trust Merge to leave alone.
See Privacy and data collection for the page you can forward to your security team or works council.
How it identifies employees
Identity is resolved server side and bound to the device; establishing it costs the employee at most one click, once. After that their machine stays set up, with their models and their approved tools already connected.
The design resolves identity by trying three mechanisms in order and using the first that works. In the current release, employee sign-in is the mechanism that ships; the two zero-touch tiers are on the roadmap.
Tier 3 is what resolves identity today: one click, authenticated by your IdP. Tiers 1 and 2 are planned so that click disappears; tier 1 will be both zero-touch and authenticated, and tier 2 zero-touch and as correct as your inventory.
In all three tiers, identity is resolved on Merge’s side. There is no configuration key, file, or registry value on the endpoint that sets it, because anything the client could read is writable by a local administrator, and an employee should never be able to present as a colleague. See identity integrity.
Every device records which tier produced its identity, and the fleet view shows it. That matters when you trace a prompt back to a person: an authenticated identity is evidence, an asserted one is a strong indication, and you should be able to tell which one you are looking at.
The optional ExpectedIdentity hint in the MDM profile is where you record the employee your MDM has on file, so a mismatch against the one Merge resolves can be flagged. That usually means a reassigned laptop with a stale inventory record, or a shared machine. Set it now if your MDM has a reliable user variable; mismatch alerting does not surface in the fleet view yet.
Access follows identity. Until a device has a resolved identity there is no governed AI path on it: the client refuses to mint a Gateway key and writes no MCP configuration. Devices in that state appear as Unattributed in the fleet view so you can fix the cause.
Tool access is granted by your organization. Once identity resolves, Merge connects that employee’s approved tools automatically, without an employee consent prompt. This is a deliberate choice for corporate-managed accounts: the grants come from the Groups you configured, so the employee never has to authorize anything. If your organization operates somewhere that expects individual notice for this, the privacy reference has the language to share.
Revoking in your IdP revokes at the endpoint. Deprovisioning an employee invalidates their session, and the client stops receiving their identity at its next heartbeat, within five minutes, which makes endpoint AI access part of offboarding rather than a separate cleanup step.
Identity is per operating system user, so shared and multi-user machines work without extra configuration.
Discovery needs no identity at all. Installed-app and MCP-config inventory runs as soon as the device enrolls, attributed to the device, and re-attributes to the employee once identity resolves.