Topic starter
27/10/2026 7:12 pm
TL;DR: Claude Code managed settings can control commands, MCP servers, model access, hooks, secrets, network tools, and bypass modes, but the breadth makes teams stall without a baseline policy, according to Willow. The practical challenge is not capability but governance: managed settings only create value when security teams define defaults before developers start using the tool.
Editorial analysis by NHI Mgmt Group, based on content published by Willow: “Claude Code Policy: Write Managed Settings Fast”.
Key questions
Q: What should security teams block first in Claude Code policies?
A: Start with the highest-risk runtime actions: shell commands that can move data, access credentials, or alter repositories.
Q: Why do managed settings matter more than local developer settings?
A: Managed settings matter because they are enforced at the system level through MDM, while local settings can be changed or bypassed by the user.
Q: How should teams decide whether to allow MCP servers in developer tooling?
A: Allow MCP servers only when they are centrally reviewed, inventory is known, and the policy can constrain which servers the agent may reach.
Practitioner guidance
- Define a baseline policy tier first Choose minimal, standard, strict, or lockdown before editing individual rules so teams are not inventing governance from a blank file.
- Block high-risk commands by default Deny or gate commands such as curl, wget, sudo, git push, scp, and rsync until there is a clear business need and approval path.
- Restrict secrets and credential file access Prevent the agent from reading .env files, secrets directories, SSH keys, AWS credentials, and service-account files unless the workflow truly requires it.
Bottom line: Claude Code governance is really a policy-design problem, because the managed-settings file controls commands, secrets, MCP access, and network reach at the system level.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →