Governing Claude Code, Cursor and Copilot with one policy

No single file governs Claude Code, Cursor and Copilot, because each tool has its own control plane. Claude Code reads managed settings from a file, MDM or the admin console. Cursor enforces team rules from its dashboard. Copilot’s cloud agent has an organization-level network firewall. This post maps what each vendor documents and where each control stops.

What each vendor documents

The three tools overlap on four things: who sets the policy, which tool calls are allowed, which MCP servers load, and which hosts an agent can reach. The vendor docs cover those four areas differently, so a single policy has to be written once and mapped three times. The sections below cover Claude Code first, because its docs name the most keys, then Cursor and Copilot. The table at the end lines them up.

Claude Code: managed settings, permission rules and the sandbox

Claude Code has the most documented controls of the three. The admin layer sits above every developer file, and a few keys make that layer the only one that counts. Start with the policy file, then lock the rules, then turn on the sandbox.

Put the policy in managed settings

Managed settings are the top level of Claude Code’s precedence stack. The order runs from managed settings at the top, then the command line through --settings, then project local, shared project and user settings. A key set higher in the stack overrides the same key below it. List keys such as permissions.allow merge across files instead of overriding, so a developer can add entries. Run /status on one machine to confirm the managed source loaded before you roll the policy out.

Lock permission rules and bypass mode

Rules are evaluated in this order: deny, then ask, then allow. The first match decides, and a broad deny such as Bash(aws *) blocks a call even when a narrower allow matches it. Setting allowManagedPermissionRulesOnly to true makes managed settings the only source of permission rules.

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Bash(aws *)", "Read(./.env)"],
    "ask": ["mcp__github__*"]
  }
}

The settings reference lists allowManagedHooksOnly, which runs only the hooks your organization deploys. It also lists allowManagedMcpServersOnly, which makes the managed allowlist the only one that applies. The settings reference gives allowedMcpServers and deniedMcpServers as separate keys. Use the allowlist to approve servers. With allowManagedMcpServersOnly set, a server a developer adds loads only if it matches the managed allowlist. The denylist is an extra, explicit block that applies to every server, including managed ones.

Turn on the sandbox for OS-level limits

The sandbox adds an OS-level layer for Bash, PowerShell and Monitor commands and the processes they start, on top of the permission rules. Set sandbox.enabled to turn it on. Set failIfUnavailable to true so Claude Code fails closed instead of running commands unsandboxed: it exits at startup if the sandbox can’t start, and if the sandbox stops working later in a session, each sandboxed command is refused. File tools, MCP servers and hooks run outside the sandbox either way. Set allowUnsandboxedCommands to false to ignore the retry parameter that lets Claude run a failed command outside the sandbox.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "allowedDomains": ["github.com", "*.npmjs.org"] }
  }
}

The docs name the sandbox key as sandbox.network.allowedDomains. A sandbox.allowedDomains key does not appear on the page, so use the nested form.

Cursor: team rules, hooks and enterprise controls

Cursor splits its controls between team rules, which are text the agent reads, and enterprise settings, which the admin enforces. Rules are the easy part to deploy. Enforcement depends on the plan and on which box an admin ticks.

Team rules: enforced or optional

Team Rules are managed from the Cursor dashboard and are available on Team and Enterprise plans. Admins set whether each rule is required for team members. An enforced rule is required for every team member and cannot be disabled in Customize. A rule that is not enforced can be turned off by each member. Precedence runs Team Rules, then Project Rules, then User Rules, and earlier sources win when guidance conflicts. The enterprise page’s plan table lists the same split as “Enforceable + Optional”.

Enterprise-only controls

The enterprise page lists controls that sit on the Enterprise plan only: a Repository Blocklist, Model Access Restrictions, and Auto-run, Browser and Network Controls. Agent Sandbox Mode is on the Individual and Teams plans too, but only Enterprise can enforce it org-wide. Hooks reach a developer’s machine through MDM on Teams, and through MDM or server-side distribution on Enterprise. The page does not give setting names for an MCP allowlist.

GitHub Copilot cloud agent: the organization firewall

The Copilot cloud agent controls network access through a firewall, not through a permission file. An admin sets the firewall at Organization > Settings > Copilot > Internet access. Enable firewall and the Recommended allowlist each take Enabled, Disabled or Let repositories decide. The default for both is Let repositories decide, so a repository can switch the firewall on or off unless the organization sets it.

The organization can also add an Organization custom allowlist. Its rules apply to every repository and cannot be deleted at the repository level. “Allow repository custom rules” is on by default, so a repository can add its own rules. The firewall applies only to processes the agent starts through its Bash tool. It does not apply directly to MCP server processes, so the network scope of a Copilot policy is narrower than the name suggests.

Compare the native controls

The table lists what each vendor’s pages describe. A cell that says “Not stated in vendor docs we checked” means the pages we read on 2026-10-31 do not describe that control. It does not mean the product lacks the feature, so check the current docs before you rely on a gap.

Control	Claude Code	Cursor	GitHub Copilot cloud agent
Admin-delivered policy	Managed settings file, MDM or OS policy, or server-managed settings	Team Rules from the dashboard; hooks by MDM (Teams) or MDM and server-side (Enterprise)	Organization > Settings > Copilot > Internet access
Enforced or optional	Managed permission rules, with `allowManagedPermissionRulesOnly`	“Enforce this rule” on or off per rule	Each firewall control set to Enabled, Disabled or Let repositories decide
Tool command rules	`allow`, `ask` and `deny`, evaluated deny, then ask, then allow	Not stated in vendor docs we checked	Not stated in vendor docs we checked
MCP server allowlist	`allowedMcpServers`, `deniedMcpServers`, `allowManagedMcpServersOnly`	Not stated in vendor docs we checked; the enterprise page names MCP trust management only	Not stated in vendor docs we checked; the firewall does not apply to MCP server processes
Hooks	`allowManagedHooksOnly` runs only deployed hooks	Distributed by MDM; server-side on Enterprise	Not stated in vendor docs we checked
Sandbox	`sandbox.enabled`, `failIfUnavailable`, `allowUnsandboxedCommands`	Agent Sandbox Mode; org-wide enforcement on Enterprise only	Not stated in vendor docs we checked
Network egress	`sandbox.network.allowedDomains`; built-in WebFetch follows permission rules instead	Network Controls, Enterprise only	Firewall with Recommended allowlist and Organization custom allowlist
Model access	`availableModels` and `deniedModels` in managed settings	Model Access Restrictions, Enterprise only	Not stated in vendor docs we checked
Repository access	Not stated in vendor docs we checked	Repository Blocklist, Enterprise only	Not stated in vendor docs we checked
Bypass or auto-run	`permissions.disableBypassPermissionsMode`	Auto-run controls, Enterprise only	Not stated in vendor docs we checked

Gotchas that weaken a shared policy

Each vendor’s docs include a limit that matters when you try to enforce one policy across tools. Read these before you call the policy done.

Claude Code sandbox scope. The sandbox covers Bash, PowerShell and Monitor commands and the processes they start. It does not cover the built-in Read, Edit, Write, WebFetch and WebSearch tools, which follow permission rules. Command hooks, local MCP servers and apiKeyHelper run with full access.
Claude Code excluded commands. Commands matched by excludedCommands run outside the sandbox, and so do unsandboxed retries when they are allowed.
Cursor advisory rules. A team rule that is not enforced is a suggestion that members can switch off.
Copilot MCP gap. The firewall does not apply directly to MCP server processes, so an MCP server’s own network calls sit outside it.

A checklist for one policy

Write the policy as a list of decisions, not as a file. Then map each decision to a key, a rule or a setting, and mark the ones a vendor does not document.

Decide which tool calls are denied, and write each as a Claude Code deny rule. Check each one against Cursor’s team rules and Copilot’s settings, where the docs name a control.
Decide which MCP servers are approved. Set the Claude Code allowlist, and record the Cursor and Copilot gap as an open item.
Turn on the Claude Code sandbox with failIfUnavailable set. Set the Cursor sandbox to org-wide enforcement only if you are on Enterprise.
Set the Copilot firewall to Enabled, set the Recommended allowlist centrally (Enabled or Disabled, not Let repositories decide), add the Organization custom allowlist, and turn off “Allow repository custom rules”. Without the last step, repositories can still add their own rules.
Write down every “Not stated” cell as a risk, and check the current vendor docs before the next review.

Enforcing this with AIControls

AIControls confirms support for Copilot in VS Code, and for Claude Code through the gateway in both the CLI and VS Code, with per-user tokens. This post makes no AIControls claim for Cursor or for the Copilot cloud agent. To see what AIControls covers for coding agents, start with the coding agents page and then request a demo. Read the managed settings guide for Claude Code before you set up the policy file on developer machines.

Frequently asked questions

Can one file govern Claude Code, Cursor and GitHub Copilot at the same time?

Not with the controls these vendors document. Claude Code reads a managed settings file or an MDM profile on each machine. Cursor sets rules in its dashboard and distributes hooks through MDM. The Copilot cloud agent is configured in the organization's Copilot settings. Each policy lives in a different place, so one policy means one written rule set that you map to each tool's keys, then check on each tool.

Do Cursor team rules stop a developer from ignoring them?

Only when an admin marks the rule as enforced. The Cursor rules page says an enforced rule is required for all team members and cannot be disabled in Customize. A rule that is not enforced can be turned off by each member. The same page warns that AI guidance should not be your only security control.

Does the Copilot cloud agent firewall cover MCP servers?

No. GitHub's firewall page says it applies only to processes the agent starts through its Bash tool. It does not apply directly to MCP server processes, so their own network calls sit outside it. Treat the MCP allowlist as a separate control, and check it against the vendor's current MCP docs.

Which Claude Code setting stops a developer from loading a rogue MCP server?

Set allowManagedMcpServersOnly to true in managed settings and list the approved servers in allowedMcpServers. The key makes the managed allowlist the only one that applies: developers can still add servers to their own settings, but only servers that match the managed allowlist load. Use deniedMcpServers on top of that to block specific servers outright; the denylist applies to every server, wherever it was configured.