Enforce coding agent rules at the organization level, not in individual files. In Claude Code, managed settings sit at the top of the precedence order and override user and project files. Share approved permission configurations through version control, review changes to them like code, and monitor usage. Other agents have their own equivalents, so check yours.
Definitions
Settings scope. Who a setting applies to: one user, everyone in a project, or everyone in an organization.
Managed settings. Settings delivered by an organization through a managed file, device management policy or a console. In the documented order they rank above the command line, local project, shared project and user levels.
Precedence. When a key is set in several places, the higher level wins.
Who can set what
| Level | Set by | Use it for |
|---|---|---|
| Managed | Your organization | Security policy and compliance requirements |
| Command line | The person for one session | Temporary overrides, within what managed settings allow |
| Local project | One developer for one project | Personal preferences |
| Shared project | The team, committed to the repository | Agreed team rules |
| User | One developer across projects | Personal defaults |
Steps
- Decide what must be uniform. Typical candidates are deny rules for secret files, which MCP servers may run, which permission modes are allowed and whether telemetry is on.
- Put those in managed settings. Use the delivery mechanism that matches your device management.
- Put team conventions in the shared project file and require review of changes, as with any config in git.
- Leave personal preferences to users at the user and local levels.
- Restrict MCP servers. The Claude Code documentation points to managed MCP configuration to control which servers run in an organization. Reviewing a project MCP file alone will not show servers from other scopes, connectors or plugins.
- Audit and block changes during sessions. The documentation mentions hooks that can audit or block settings changes while a session runs.
- Train people. The vendor's team guidance includes training members on security practices.
- Test as a new hire would. Start a fresh machine with only managed settings and see what the agent can do.
Common gaps
- Rules only in a project file that a developer can override locally.
- No rule on which MCP servers are allowed.
- Managed settings deployed to laptops but not to build agents.
- Telemetry that was never turned on, so you cannot see usage.
- Nobody owns the settings repository.
Quick check
Can a developer override managed settings?
Per the documented precedence, managed settings are at the top and are not edited by the developer. Verify the behavior for each key you depend on.
Should project settings be committed to the repository?
Shared team rules, yes, with review. Keep personal or local settings out of version control.
Does this apply to other coding agents?
The idea does. Look for the equivalent of an organization policy layer in your tool and compare it with this structure.
Where Safeguard fits
Safeguard offers policies, gates and guardrails, asset discovery to find which agents and MCP servers run in your environment, and compliance evidence automation. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
