What you will be able to do
- Write managed permission rules and lock them so developers cannot loosen them
- Control which MCP servers a team can use, and know which channel can carry each MCP control
- Restrict models and effort, set version floors, and predict how a policy change reaches running sessions
1.Permission rules and permission lockdown
After choosing how policy reaches machines, an admin decides what that policy enforces. The most direct control is permission rules: permissions.allow, permissions.ask and permissions.deny approve, prompt for, or block specific tools and commands. A deny rule can block reads of files that hold secrets. Permission rules can live in any settings file, though, and that becomes a problem once a team depends on them for security.
A security lead configures a project-level deny rule Bash(aws *) to block all AWS CLI usage from Claude Code. A developer later adds an allow rule Bash(aws s3 ls) to their local settings so they can list bucket contents. When the developer runs aws s3 ls in a session, what happens?
Correct answer: A — The command is blocked, because deny rules are evaluated before allow rules and a broad deny cannot carry allowlist exceptions from a narrower allow rule
- A. Correct. Rules are evaluated in the fixed order deny, then ask, then allow, and rule specificity does not change that order, so a broad deny rule like Bash(aws *) blocks every matching call even when a narrower allow rule also matches.
- B. Incorrect. Specificity does not override the deny-first evaluation order; a narrower allow rule matching the same call as a broader deny rule still loses to the deny rule.
- C. Incorrect. There is no rule-merging step that converts a deny/allow conflict into an ask prompt; the deny rule wins outright and the command is blocked with no prompt.
- D. Incorrect. Local settings can add stricter or looser rules within their own scope, but they do not grant an exception to a deny rule defined at a different scope, since deny rules from any scope are evaluated before allow rules.
Two managed keys close the gap. allowManagedPermissionRulesOnly makes managed settings the only settings source of permission rules, so allow rules in user, project or local files no longer count. permissions.disableBypassPermissionsMode prevents anyone from entering bypassPermissions mode, which the admin guide pairs with disabling --dangerously-skip-permissions. The server-managed settings guide shows both keys together.
{
"permissions": {
"deny": [
"Bash(curl *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}An organization's Owner wants to guarantee that only permission rules defined centrally by the security team take effect for every developer, so that even a well-intentioned engineer cannot loosen a restriction by editing their own settings. Which managed setting accomplishes this?
Correct answer: B — Set allowManagedPermissionRulesOnly to true, so user and project settings can no longer define any allow, ask, or deny rules
- A. Incorrect. This key locks down which MCP servers can be added or connected to; it has no effect on general permission rules like Bash or file access allow, ask, and deny entries.
- B. Correct. allowManagedPermissionRulesOnly is a managed-only setting that, when true, prevents user and project settings from defining any allow, ask, or deny permission rules at all, so only the rules the security team places in managed settings apply.
- C. Incorrect. This setting only blocks the bypassPermissions mode from being enabled; it does not stop developers from adding their own allow or ask rules in other permission modes.
- D. Incorrect. This setting restricts which plugin marketplace sources can be added, which is unrelated to permission rules for tools like Bash, Read, or Edit.
Permission rules decide what Claude may try. For defence in depth, the admin guide lists more enforcement layers. Sandboxing (sandbox.enabled, sandbox.network.allowedDomains) adds OS-level filesystem and network isolation. A managed policy CLAUDE.md loads org-wide instructions into every session. allowManagedHooksOnly runs only the hooks your organization deploys. forceLoginMethod and forceLoginOrgUUID restrict login to a specific method or organization.
2.Controlling MCP servers for a team
MCP servers extend what Claude Code can reach, so they need the same governance as tools. The admin guide groups the controls together: restrict which servers users can add or connect to, deploy a fixed set, or give every user remote servers alongside their own.
| Key | What it does | Scope |
|---|---|---|
| allowedMcpServers | Allowlist which MCP servers users can add | Any file |
| deniedMcpServers | Block specific MCP servers by URL, command, or name | Any file |
| allowManagedMcpServersOnly | Make the managed MCP allowlist the only one that applies | Managed |
| managedMcpServers | Provide remote MCP servers to every user alongside the ones they add | Managed |
| disabledMcpjsonServers | Reject specific servers from a project's .mcp.json | Any file |
| strictPluginOnlyCustomization.mcp | Lock MCP servers to plugin and managed sources | Managed |
The delivery channel matters here. A deployed managed-mcp.json file sets a fixed server list, but it cannot be distributed through server-managed settings. In the admin console you deliver the allowedMcpServers and deniedMcpServers keys instead. From Claude Code v2.1.259 you can also use managedMcpServers, which accepts only http and sse servers and, unlike the file, does not take exclusive control. A managed-mcp.json placed at its system path is read separately from the managed settings tier, so it still applies when server-managed settings are in effect.
3.Models, effort and version floors
These sources do not describe a spend-cap setting in Claude Code itself. The controls that shape model usage are model restrictions and an effort cap. availableModels filters which models appear in the picker. On its own it does not stop the default model from falling outside the list. Adding enforceAvailableModels: true resolves Default to the first available model in the list. deniedModels is managed-only, and blocks a model even when availableModels permits it. maxEffortLevel caps the effort level for every model or per model, on every provider. modelPricing does not restrict anything: it makes Claude Code report spend at your contracted rates instead of list price.
{
"availableModels": ["opus", "sonnet"],
"deniedModels": ["claude-opus-5-5"]
}Version control comes in two strengths. minimumVersion keeps auto-update from installing anything below an org-wide floor. requiredMinimumVersion and requiredMaximumVersion go further: Claude Code refuses to start at all outside the approved range. Both required keys are managed-only.
Sources2
4.How a policy change reaches running sessions
Most changes reach a running session on the delivery schedule, without a restart. There are exceptions. requiredMinimumVersion and forceRemoteSettingsRefresh take effect only at the next session start. A server-managed change to a setting that needs approval, such as a hook or an env variable, waits for the developer to accept a dialog in an interactive session. A session left open for weeks can still lag a rollout, because a version floor blocks an old binary from starting but does not end a session that is already running.
Fetch failures matter too. If the server-managed fetch fails, Claude Code continues with endpoint-managed settings, or with its cached server policy, and warns in interactive sessions. An organization that cannot accept that gap sets forceRemoteSettingsRefresh, which makes Claude Code exit instead.
It runs without server-managed settings. Claude Code warns in the interactive session that no remote policy applies, and any endpoint-managed settings (MDM or the managed file) still apply. If forceRemoteSettingsRefresh were set in a managed source, Claude Code would exit instead.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.To give every developer a fixed MCP server set, upload managed-mcp.json through the claude.ai admin console.Why is that wrong?
managed-mcp.json cannot be distributed through server-managed settings. Deliver allowedMcpServers and deniedMcpServers there, or use managedMcpServers for http/sse servers, and deploy the file to its system path through other means.
Covered in Controlling MCP servers for a team
2.Setting minimumVersion guarantees that no developer can run a Claude Code version older than the approved floor.Why is that wrong?
minimumVersion only stops auto-update from installing below the floor. To refuse startup outside an approved range, use requiredMinimumVersion and requiredMaximumVersion.
Covered in Models, effort and version floors
Practise it for real
Deploy a file-based managed policy on a Linux or WSL machine that denies reads of secret files, disables bypass mode, and makes managed permission rules the only source.
1.Write a managed-settings.json with permissions.deny for Read(./.env) and Read(./secrets/**), permissions.disableBypassPermissionsMode set to "disable", and allowManagedPermissionRulesOnly set to true.
Why: These three keys together block secret reads, remove the bypass escape hatch, and stop user or project allow rules from loosening the policy.
You should see: A valid JSON file with the same shape as the managed-settings example in the docs.
2.Copy the file to /etc/claude-code/managed-settings.json (on macOS, /Library/Application Support/ClaudeCode/managed-settings.json). Writing a system path needs admin rights.
Why: File-based managed settings are read only from the fixed system directory.
You should see: The file exists at the system path, owned by an administrator.
3.Start a Claude Code session in a project containing a .env file and run /status.
Why: /status reports which setting sources loaded, so you can confirm the managed file is in effect.
You should see: The managed file appears among the setting sources.
4.Ask Claude to read .env, then try to switch into bypassPermissions mode.
Why: This confirms that the deny rule and the bypass lock both apply.
You should see: The read is blocked by the deny rule and bypassPermissions mode is unavailable.
Stuck? Get a nudge
If the policy does not seem to apply, check that the path is exact. Claude Code reloads the file when it changes, so you do not need to reinstall.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/admin-setupOfficial docs
“Make managed settings the only settings source of permission rules. Disable --dangerously-skip-permissions”
↩︎ Permission rules and permission lockdown“OS-level filesystem and network isolation with domain allowlists”
↩︎ Permission rules and permission lockdown“Restrict which MCP servers users can add or connect to, deploy a fixed set, or provide remote servers to every user alongside their own”
↩︎ Controlling MCP servers for a team“Refuse to start at all when the running version is outside an org-approved range. Stronger than minimumVersion, which only blocks downgrades”
↩︎ Exam trap 2 - 2.https://code.claude.com/docs/en/settings-referenceOfficial docs
“Block listed tool uses, including reads of files that hold secrets”
↩︎ Permission rules and permission lockdown“when Default would resolve to a model outside availableModels, Claude Code resolves it to the first available model in the list”
↩︎ Models, effort and version floors“Report spend at your organization’s contracted rates instead of list price”
↩︎ Models, effort and version floors - 3.
“which accepts http and sse servers only”
↩︎ Controlling MCP servers for a team“If a managed source sets forceRemoteSettingsRefresh, Claude Code exits instead”
↩︎ How a policy change reaches running sessions“Deliver the allowedMcpServers and deniedMcpServers policy keys there instead.”
↩︎ Exam trap 1 - 4.https://code.claude.com/docs/en/managed-settingsOfficial docs
“waits for the developer to accept the dialog in an interactive session”
↩︎ How a policy change reaches running sessions“a session left open for weeks can still lag a rollout”
↩︎ How a policy change reaches running sessions