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.
At a glance
What this is: This is a practical policy guide for governing Claude Code through managed settings, with the core finding that broad control surface area makes baseline policy design the real blocker.
Why it matters: It matters because developer AI tools can access commands, secrets, and MCP servers on endpoints, so IAM and security teams need enforceable policy before rollout rather than ad hoc review after adoption.
Context
Claude Code policy control matters because the managed-settings file is both powerful and easy to misconfigure. The security problem is not whether the tool can be governed, but whether teams can define usable defaults before developers start relying on it.
For security and platform teams, the key governance question is how to convert a broad local control surface into enforceable endpoint policy. That is the difference between managed deployment and a set of settings that exist only on paper, especially when AI coding agents can reach commands, files, secrets, and network tools.
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. In practice, block or gate commands such as sudo, git push, scp, rsync, curl, and wget first, then expand toward files, network access, and MCP connections once the baseline is stable.
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. That makes managed policy the only reliable place to define what the agent may do on a developer machine.
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. If developers can add unreviewed servers on their own, the tool becomes an uncontrolled access path rather than a governed integration.
Q: What is the safest rollout model for AI coding agent governance?
A: Use a baseline, deploy it centrally, and then relax controls only where the workflow proves necessary. That approach avoids one-off exceptions and gives security teams a repeatable way to manage secrets access, command execution, and network reach as usage expands.
Technical breakdown
How Claude Code managed settings enforce system-wide controls
Claude Code managed settings are applied at the machine level and pushed through an MDM, which means they operate as policy rather than user preference. That distinction matters because local settings can be edited or bypassed, while managed settings govern what commands the agent can run, what files it can read, and which integrations it can reach. In practice, the control point is the endpoint, not the IDE prompt or the developer account. This turns the policy file into an access boundary for the coding agent itself. Practical implication: treat the managed-settings file as an enforceable endpoint control, not a configuration suggestion.
Practical implication: Define policy in the managed file, then push it through MDM so the control is enforced outside developer reach.
Why command, secrets, and MCP restrictions belong in one policy
The article groups Bash commands, secrets access, MCP servers, model login, and network tools into a single policy surface because those controls govern the same runtime risk: what the agent can touch and where it can send data. If commands are allowed but secret reads are not, or MCP is open but egress is not, the control model becomes inconsistent and easy to misunderstand. This is especially important for AI coding agents because the risk is not just code generation, but tool use across local files, credentials, and external services. Practical implication: design one coherent allow, ask, or block policy across commands, files, and tool integrations.
Practical implication: Align command execution, file access, and MCP access under one policy model so the agent cannot bypass governance through another channel.
Why baseline tiers matter for policy adoption
The article’s minimal, standard, strict, and lockdown tiers are not just packaging. They are a governance mechanism for reducing the cognitive load of policy creation, which is often the real reason teams fail to deploy controls. A baseline gives security and platform teams a starting point that already encodes a risk posture, then allows local adjustment without rebuilding the policy from scratch. That approach is especially useful when the alternative is an empty JSON file and no shared security standard. Practical implication: choose a default tier first, then tune exceptions instead of designing every rule from zero. See the Security Policy Framework Guide.
Practical implication: Start from a hardened baseline tier so teams can approve a policy quickly and then refine it by exception.
Threat narrative
Attacker objective: The attacker objective is to turn an AI coding agent and its surrounding developer tooling into a path for secrets exposure, unapproved actions, or downstream compromise of the codebase.
- Entry occurs when a developer installs or uses an AI coding agent with broad local access on the workstation or inside the development environment.
- Credential access happens when the agent can read secrets files, AWS credentials, SSH keys, or raw API keys that were left accessible on disk.
- Escalation follows when the agent is allowed to run shell commands, reach MCP servers, or use network tools that extend its reach beyond the intended workflow.
- Impact is unauthorized code execution, secret exposure, or data movement through developer tooling that was never meant to act as a governed identity boundary.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Policy baseline is the real control plane for AI coding agents: The article shows that the hard problem is not whether Claude Code can be governed, but whether teams can operationalize a stable policy before adoption spreads. That is the same governance pattern NHI teams face with any high-privilege software identity: if the default posture is unclear, the rollout becomes the control failure. The practitioner lesson is to treat policy design as a prerequisite to deployment, not a cleanup step after users start working.
Secrets access inside developer tooling is identity governance, not just app hardening: When an agent can read .env files, SSH keys, AWS credentials, or service-account files, the governance issue is no longer limited to software development. It becomes a question of who or what is allowed to access machine credentials during runtime, which places this squarely in NHI governance and endpoint control. Teams that still think in terms of application permissions alone miss the delegated identity risk in the workstation layer.
Managed settings expose a classic assumption gap in developer governance: The policy model assumes local settings are unreliable and can be bypassed, so enforcement must happen outside the user’s control. That assumption fails if teams keep relying on voluntary compliance, informal review, or copied JSON snippets. The implication is that the security model must move from trust in developer behavior to enforced machine policy.
AI coding agents need lifecycle governance, not one-time approval: A policy file is only useful if it is maintained, reviewed, and aligned with the way teams actually use the tool over time. The presence of managed settings, MDM delivery, and tiered baselines shows that this is a lifecycle problem as much as a configuration problem. Practitioner teams should govern agent access the same way they govern other non-human identities: by policy, scope, and ongoing review.
Shadow AI becomes a control gap when one agent policy does not cover the rest of the stack: The article rightly notes that developers may also be using other assistants and MCP servers outside the primary policy boundary. That is a governance warning, not a tooling footnote. If the organisation only controls one approved agent while ignoring the rest of the runtime estate, it has created a partial control model that cannot prove effective.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Coding Agents Security Guide
What this signals
Managed settings turn AI coding agents into governable endpoint identities: The practical shift is from trusting the user of the tool to constraining the tool’s runtime behaviour on the machine. That matters because policy boundaries around commands, secrets, and network access only work when they are enforced outside the developer session, not negotiated inside it.
The next governance problem is coverage, not capability. If one agent is locked down but the rest of the developer stack still has unrestricted access to secrets, MCP servers, and external tools, the organisation has reduced risk in one place while leaving a broader runtime boundary undefined.
For practitioners
- 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. See the Security Policy Framework Guide.
- 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.
- Centralise policy deployment through MDM Push managed settings through Jamf, Intune, or group policy so the policy is enforced at the system level instead of by developer discretion.
- Review MCP and network access together Treat managed MCP servers, WebFetch, WebSearch, curl, wget, and nc as one governance surface rather than separate exceptions.
Key takeaways
- 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.
- Developer convenience does not replace enforceable governance, since local settings can be bypassed while managed settings are pushed through MDM.
- The strongest rollout pattern is to start from a baseline tier, then tighten or relax controls based on actual workflow needs and risk tolerance.
Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Security Policy Framework Guide · Cloud Misconfiguration Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on controlling what an AI coding agent can do with commands, files, and integrations. |
| Recommendation — Constrain the agent’s reachable tools and privileges so runtime action stays inside approved boundaries. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Managed settings govern how the agent authenticates, including blocking raw API keys and forcing approved login. |
| NHI-05 — Overprivileged NHI | The policy examples focus on reducing excessive access to commands, secrets, and network tools. | |
| Recommendation — Require approved authentication paths and block unmanaged credentials from agent startup and use. Reduce the agent’s accessible commands, files, and integrations to the minimum needed for the task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article explicitly addresses API keys and credential handling inside the developer workflow. |
| AC-6 — Least Privilege | The whole policy model is about limiting what the agent can execute or access on the endpoint. | |
| Recommendation — Manage and restrict authenticators used by developer tools so exposed credentials cannot be reused unchecked. Apply least privilege to the agent’s runtime access, commands, and file reads on developer machines. | ||
Key terms
- Managed Settings: A persistent configuration layer that defines what an AI coding tool may do, what it must ask about, and what it cannot touch. For identity teams, this becomes the policy boundary that governs command execution, tool use, and exposure to sensitive paths.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Policy Baseline: A policy baseline is the vendor or organisation's expected security state for a setting, rule, or configuration. It proves alignment with a standard, but not whether the control meaningfully reduces risk in production or disrupts attacker behaviour.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org