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 and Windows. 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 and Windows

Managed settings are administrator-protected on both platforms, so the tamper-resistance guarantees are the same:
PlatformWho can change enforcement
macOSOnly an administrator. Standard users can’t edit or remove the managed settings.
WindowsOnly an administrator. Standard users can’t edit or remove the managed settings.
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": true
}
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.