Workforce desktop client overview

A managed desktop client that provisions the governed AI stack on every employee machine and reports AI usage back to Merge

The Merge Workforce desktop client is a small background service you deploy to employee laptops through your MDM. It installs and keeps current the governed AI stack (the Merge CLI, Agent Handler MCP configuration, and the AI software you sanction), optionally makes that stack the only AI path available, and reports which AI tools employees are using so you can see your whole AI footprint in one place.

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.

Modules

Every capability is a module you turn on independently, per organization and per Group. You compose the client you want, from a silent inventory sensor to full provisioning with enforcement.

ModuleWhat it doesAdmin-configurable
Software provisioningInstalls and updates the Merge CLI, writes the Agent Handler MCP configuration, and installs the AI software in your catalog☑️
Gateway-only enforcementKeeps AI harnesses pointed at Gateway, and blocks direct model provider endpoints☑️
MCP allowlistMakes the Agent Handler MCP server the only MCP server employees can register☑️
Shadow AI loggingInventories installed AI apps, IDE assistants, CLI agents, MCP servers, and AI web usage☑️
Menu bar appControls whether employees see nothing, a tray icon, or a panel showing their own usage and access☑️

Every module is independently enabled or disabled, so nothing in the table above is on unless you turn it on.

Enforcement modules have three modes:

  • Observe reports what would have happened and changes nothing
  • Revert restores configuration you own when it drifts
  • Block additionally blocks the ungoverned network path

Start every enforcement module in observe mode. Newly enrolled devices also stay in observe mode for their first 24 hours regardless of your setting, so a policy mistake cannot cut off AI access across a fleet in the first minutes of a rollout.

What it collects

The client reports metadata, not content. Specifically, it collects:

  • Installed AI applications, IDE AI extensions, and CLI agents, with version and last-used timestamps
  • MCP servers found in harness configuration files, including whether a plaintext secret is present in the file. The secret value is never transmitted
  • AI network flows as five-minute rollups of process, destination, request count, and byte counts
  • Provisioning and enforcement state per device
What it never collects

It does not 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.

TierMechanismEmployee actionWhat it proves
1Silent SSO. A token for the signed-in user from your IdP, via Entra join on Windows or Platform SSO on macOS 13+NoneAuthenticated. The IdP vouches for who this is
2MDM-assigned. The assigned user, read by Merge from your MDM’s API by serial numberNoneAsserted. As accurate as your device inventory
3Employee sign-in. A one-time OAuth prompt from the menu barOne clickAuthenticated

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.

Mismatches are a signal, not an error

If you set the optional ExpectedIdentity hint in the MDM profile, the client raises a mismatch alert when the employee Merge resolves differs from the one your MDM has on file. That usually means a reassigned laptop with a stale inventory record, or a shared machine.

Access follows identity. Until a device has a resolved identity there is no governed AI path on it: no Gateway key, no MCP configuration, and with enforcement enabled the direct provider endpoints are blocked too. 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 blocks at its next check-in, within 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.

Next steps