> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getunbound.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Tamper Resistance

> Keep Unbound enforcement active on every device using managed settings

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.

<CardGroup cols={2}>
  <Card title="Standard users can't remove it" icon="user-lock">
    Managed settings live in an administrator-owned, protected location. A standard (non-admin) user can't modify or delete them.
  </Card>

  <Card title="It takes precedence" icon="layer-group">
    Managed settings override personal settings, so a user can't disable enforcement by changing their own configuration.
  </Card>
</CardGroup>

<Note>
  Managed deployment must be run with administrator privileges. See [Deploy AI Tools via MDM](/mdm-integrations/deploy-ai-tools) for the per-tool install commands.
</Note>

## 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.

<Steps>
  <Step title="Deploy via MDM">
    Push the [MDM install command](/mdm-integrations/deploy-ai-tools) for each AI tool to your managed devices.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Confirm on the Devices page">
    Review the [Devices page](https://gateway.getunbound.ai/settings?tab=devices) to confirm enforcement is active across your fleet.
  </Step>
</Steps>

## Keep an eye on your fleet

The [Devices page](https://gateway.getunbound.ai/settings?tab=devices) 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.

<Tip>
  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.
</Tip>

## macOS and Windows

Managed settings are administrator-protected on both platforms, so the tamper-resistance guarantees are the same:

| Platform    | Who can change enforcement                                                       |
| ----------- | -------------------------------------------------------------------------------- |
| **macOS**   | Only an administrator. Standard users can't edit or remove the managed settings. |
| **Windows** | Only an administrator. Standard users can't edit or remove the managed settings. |

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

### 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.

```json theme={null}
{
  "wslInheritsWindowsSettings": true
}
```

<Note>
  `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](mailto:support@unboundsecurity.ai) if you'd like help setting up the Windows policy layer.
</Note>

### Best practices for WSL

<CardGroup cols={2}>
  <Card title="Set the inheritance flag" icon="link">
    Set `wslInheritsWindowsSettings: true` in your Windows managed settings whenever anyone on the fleet uses WSL.
  </Card>

  <Card title="Prefer the native Windows install" icon="windows">
    For managed fleets, install Claude Code natively on Windows (administrator-protected) rather than via npm inside WSL where you can.
  </Card>

  <Card title="Deliver via GPO or Intune" icon="cloud">
    Push the Windows managed settings through Group Policy or Intune so the OS reapplies them on its own schedule.
  </Card>

  <Card title="Monitor the Devices page" icon="display">
    If WSL is required, pair the flag with a regular Devices-page review to catch any device that stops reporting.
  </Card>
</CardGroup>

## Best practices

<CardGroup cols={2}>
  <Card title="Deploy through MDM" icon="cloud">
    Use managed deployment rather than per-user setup so enforcement is administrator-owned from the start.
  </Card>

  <Card title="Run daily" icon="clock-rotate-left">
    A daily schedule restores any removed or changed settings within 24 hours.
  </Card>

  <Card title="Limit local admin rights" icon="shield-halved">
    Standard users can't touch managed settings — keeping admin rights scarce keeps enforcement intact.
  </Card>

  <Card title="Review the Devices page" icon="display">
    Check in regularly to confirm every device is still reporting and enforcement is active.
  </Card>
</CardGroup>

<Note>
  Questions? Reach us in Slack or email [support@unboundsecurity.ai](mailto:support@unboundsecurity.ai).
</Note>