# How do I roll out coding-agent security with Jamf, Intune or Kandji?

> Push each agent's managed settings through the device management you already run, then add a monitor installed the same way, in the right user context.

Most of what you want to enforce on coding agents can be pushed as files, and your device management already pushes files. Do that first. It costs nothing beyond the time to write the settings.

## Managed settings each agent reads

| Agent | What to push | What it locks |
|---|---|---|
| Claude Code | A managed settings file, such as `/Library/Application Support/ClaudeCode/managed-settings.json` on a Mac or `/etc/claude-code/managed-settings.json` on Linux | Permission rules, the `env` block (for example OpenTelemetry export), MCP allowlists, and `permissions.disableBypassPermissionsMode: "disable"`, which refuses bypass mode and `--dangerously-skip-permissions` |
| Codex | `requirements.toml` | `allowed_sandbox_modes` and `allowed_approval_policies`, for every user on the machine |
| Cursor | Its run mode setting | `approvalMode: "allowlist"`, the Allowlist run mode, in which Cursor asks before commands not on the allowlist |
| Gemini CLI | System settings | `security.disableYoloMode: true`, `security.folderTrust.enabled: true` |
| VS Code and its forks | Settings, or policy where VS Code supports it | `chat.tools.global.autoApprove: false`, `security.workspace.trust.enabled: true` |

Where an agent has managed settings, they take precedence over what a developer sets, which is the point. Write them, test them on one machine, and push them as a configuration profile or a script.

## What managed settings do not give you

- **Whether they are in place.** A pushed file says what should be true. It does not tell you which machines run an agent you never configured, or a session started with a flag that the file does not cover.
- **A view across agents.** Each agent has its own file, its own keys and its own idea of a permission mode.
- **What actually happened.** Settings prevent; they do not record. You still need an [audit trail](/guides/audit-trail).

## Adding Golem through MDM

Golem installs with the same one-line installer on every machine, so a rollout is a question of who runs it and in what order.

**Run it as the right account.** On macOS and Linux the Golem agent is a per-user service, so an MDM script running as root must hand the install to the signed-in user. On a Mac:

```bash
uid=$(stat -f %u /dev/console)
user=$(id -un "$uid")
launchctl asuser "$uid" sudo -u "$user" /bin/sh -c \
  'curl -fsSL https://app.golem.team/install.sh | GOLEM_WORKSPACE_KEY=glk_... GOLEM_NO_SANDBOX=1 sh -s -- --with-editor-ext'
```

On Windows the agent is a machine service, so `install.ps1` runs as SYSTEM, and a second script runs `golem setup-client` as each signed-in user to connect their agents.

**One enrollment key per wave.** The key in `GOLEM_WORKSPACE_KEY` is used once and not written to the machine, but it is visible in your MDM script. Create one per wave so a leaked key can be revoked without touching the next.

**Watch before you enforce.** Start rule packs in Shadow, where every rule records what it would have done and stops nothing. Two things enforce from the first minute: the built-in rule that blocks catastrophic shell commands, and, on macOS, the shell jail around Claude Code's shell commands.

**Read the posture report.** Within minutes each machine reports how its agents are set up to run, under **Security Inventory → Agent settings**: Claude Code in bypass mode, Cursor in Run Everything, Codex with `danger-full-access`, Gemini CLI started with `--yolo`, and more. Each row names the managed setting that would lock it. Golem reads settings files every 10 minutes and the command lines of running agents, so a launch flag shows too. See [The posture report](/fleet#the-posture-report).

**Check the rollout.** `golem doctor` exits non-zero when anything is broken, which suits a compliance script. Do not take the installer's exit status as proof that agents are reporting.

## Things that catch people out

- Claude Code's `strictPluginOnlyCustomization` managed setting blocks hooks and MCP servers from user settings, which is where Golem's entries live. A machine with it set looks healthy and reports nothing.
- Labels set at install (`GOLEM_LABELS`) reach the Golem agent on Linux and Windows, but not yet on macOS, so a label rule will not place a Mac in its group. Add Macs by hand for now.
- A root install on macOS produces a machine that looks enrolled and never reports. `golem join` refuses to enroll under `sudo`.

## What Golem does not do

- It never changes an agent's settings. The posture report tells you; the fix goes through your MDM.
- It cannot stop a program from starting. A risky mode is something a rule acts on while the session runs, through `entry.permission_mode`.
- A machine that never installed the Golem agent does not appear. Your device management is the list of machines that should have it.

## Read next

- [Roll out to a fleet](/fleet): the full rollout, including removal
- [Install Golem](/install): installer options
- [What happens when developers run agents with permission prompts off?](/guides/permission-prompts-off)