Skip to main content
When you deploy Unbound through your MDM, enforcement is installed as managed settings — administrator-level configuration that standard users can’t change or remove. This keeps Unbound active on every device, even if a user tries to turn it off, and it works the same way on macOS, Windows and Linux. This page covers why managed settings are tamper-resistant, how to keep them in place with a daily schedule, and how to spot devices where enforcement has drifted.

​
Why managed settings are tamper-resistant

Deploying through MDM is different from a per-user install. Instead of writing configuration into each user’s personal settings — which that user can edit — Unbound is installed into the device’s managed settings, owned by the administrator.

Standard users can't remove it

Managed settings live in an administrator-owned, protected location. A standard (non-admin) user can’t modify or delete them.

It takes precedence

Managed settings override personal settings, so a user can’t disable enforcement by changing their own configuration.
Managed deployment must be run with administrator privileges. See Deploy AI Tools via MDM for the per-tool install commands.

​
Reapply on a daily schedule

Schedule the MDM deployment to run once a day on each device. A daily run keeps enforcement resilient: if a setting is ever changed or removed, the next run restores it automatically — so any gap closes within 24 hours without manual intervention.
1

Deploy via MDM

Push the MDM install command for each AI tool to your managed devices.
2

Run it daily

Configure your MDM platform to re-run the same command on a daily schedule. Re-running is safe — it reapplies the managed settings and changes nothing on devices that are already correct.
3

Confirm on the Devices page

Review the Devices page to confirm enforcement is active across your fleet.

​
Keep an eye on your fleet

The Devices page gives you a fleet-wide view of where Unbound is active and when each device last reported in. Use it to confirm coverage: a device that hasn’t reported recently, or that an administrator knows was reinstalled, is worth a closer look. When a device needs attention, an administrator can re-run the MDM deployment on it at any time to restore enforcement immediately, and the daily schedule does this automatically.
Pair the daily schedule with a regular Devices-page review. The schedule heals drift automatically; the review tells you which devices keep needing it, so you can follow up with those users.

​
macOS, Windows and Linux

Managed settings are administrator-protected on every platform, so the guarantee on the enforcement wiring is the same: One difference is worth knowing. Windows stores Unbound’s environment values machine-wide, so changing them needs administrator rights. macOS and Linux have no machine-wide equivalent, so the same values are written into each user’s shell profile alongside a per-user config file. A standard user can edit those and stop their own device reporting — the enforcement wiring above stays administrator-owned either way, and the daily re-run restores the values within 24 hours. It is the strongest reason to keep the schedule daily rather than weekly.
If users on a device have local administrator rights, they can change administrator-level settings. To keep enforcement fully tamper-resistant, limit local admin rights and rely on the daily schedule and Devices-page review to catch any changes.

​
Windows Subsystem for Linux (WSL)

Many developers run AI coding tools like Claude Code inside WSL (Windows Subsystem for Linux) rather than directly on Windows. WSL needs special attention, because it can sidestep the tamper-resistance guarantees above if it isn’t configured correctly.
Inside a WSL distribution, a standard Windows user can become root with no Windows administrator rights — for example with sudo (most distributions set up a sudo-capable user on first launch), or by starting WSL as root from a Windows terminal (wsl -u root). Neither triggers a Windows UAC prompt. So the Linux-side managed settings file isn’t administrator-protected the way it is on native Windows or macOS — a WSL user can edit or remove it and disable enforcement.

​
Close the gap with wslInheritsWindowsSettings

Set wslInheritsWindowsSettings: true in your Windows managed settings. Claude Code running inside WSL then also reads the Windows-side managed settings, with the Windows settings taking precedence. Because those Windows settings require administrator rights to change, a WSL user can no longer override enforcement.
wslInheritsWindowsSettings is honored only from OS-level Windows managed settings — delivered through Group Policy (GPO) or Intune to HKLM\SOFTWARE\Policies\ClaudeCode, or the managed settings file under C:\Program Files\ClaudeCode. It is not applied from server-managed (cloud) settings, so WSL hardening depends on the MDM-delivered endpoint settings.If you currently deploy Unbound only through server-managed (cloud) settings, add an OS-level Windows managed-settings layer — via GPO or Intune to HKLM\SOFTWARE\Policies\ClaudeCode, or the C:\Program Files\ClaudeCode file — on any device that can run WSL. Reach out to support@unboundsecurity.ai if you’d like help setting up the Windows policy layer.

​
Best practices for WSL

Set the inheritance flag

Set wslInheritsWindowsSettings: true in your Windows managed settings whenever anyone on the fleet uses WSL.

Prefer the native Windows install

For managed fleets, install Claude Code natively on Windows (administrator-protected) rather than via npm inside WSL where you can.

Deliver via GPO or Intune

Push the Windows managed settings through Group Policy or Intune so the OS reapplies them on its own schedule.

Monitor the Devices page

If WSL is required, pair the flag with a regular Devices-page review to catch any device that stops reporting.

​
Best practices

Deploy through MDM

Use managed deployment rather than per-user setup so enforcement is administrator-owned from the start.

Run daily

A daily schedule restores any removed or changed settings within 24 hours.

Limit local admin rights

Standard users can’t touch managed settings — keeping admin rights scarce keeps enforcement intact.

Review the Devices page

Check in regularly to confirm every device is still reporting and enforcement is active.
Questions? Reach us in Slack or email support@unboundsecurity.ai.

​
Seeing tampered setups in the dashboard

When a device’s Unbound setup is removed or altered, it surfaces in three places:
  • Home — a Tampered Devices recommendation counting the affected machines, captioned “Unbound setup was changed or removed”. Click it to open the user list filtered to those people.
  • Users — arriving from that card applies an Unbound Setup: Removed filter, which stays in the URL so the view can be shared.
  • The user side panel — an Unbound Setup section headed Setup Tampered, listing each affected machine by serial number and, beneath it, one line per tool: Setup removed where the managed configuration is gone entirely, Setup modified where only the hook script was lost.
Developers can repair their own machines with unbound doctor --fix.
Read this as “needs attention now”, not as an audit trail. Specifically:
  • It covers MDM-deployed installs only. A per-user install that a developer deletes is never counted here.
  • It is retrospective — nothing is detected until the setup command next runs on that device, so there is up to a full schedule interval of lag.
  • Offline is not tampered. A device that is switched off, off the network, or whose scheduled run has stopped firing reports nothing and will not appear. Coverage gaps belong to the Devices view instead.
  • A first-ever install is never flagged.
  • It clears itself — a later clean run drops the device off the list.
  • No timestamp of the tampering is shown, deliberately: only the date of the discovery run is knowable.
  • There is no webhook and no notification.
This is different from the Tampered status unbound doctor reports. That is one machine’s local verdict, run by the developer on demand. This is your fleet-wide view, built from what devices report back.