Copilot JetBrains Enterprise Settings Rollout Guide

A Copilot JetBrains enterprise settings rollout gives administrators a centrally managed baseline for plugins, MCP servers, telemetry, and permission modes across supported JetBrains development environments. Success depends on policy design, representative testing, exception handling, observability, and developer communication—not merely committing one JSON file.

GitHub announced enterprise managed settings for Copilot in JetBrains on August 18, 2026. The available controls cover plugin marketplaces, enabled plugins, allowed or denied MCP servers, OpenTelemetry routing, and prevention of bypass or autopilot permission modes.

Inventory users, IDEs, and existing customizations

JetBrains environments vary by product, version, operating system, project type, plugin channel, and local configuration. Build a representative inventory before enforcing policy.

Capture:

• IDE products and versions in active use.

• GitHub Copilot plugin versions and update channels.

• Operating systems and device-management coverage.

• Existing plugins, marketplaces, and agent extensions.

• MCP servers used by teams and their business owners.

• Current telemetry and content-capture settings.

• Permission bypass habits and approved automation.

• Contractors, subsidiaries, and unmanaged devices.

Do not design policy solely around the platform engineering team. Java, Android, data, and infrastructure groups may use different tools and legitimate internal servers.

Establish the policy source and ownership

GitHub's managed-settings general availability announcement describes maintaining copilot/managed-settings.json in a selected .github-private repository. Managed values take precedence over supported developer settings.

Treat the repository like production policy code. Define:

1. Enterprise owner for policy intent.

2. Engineering maintainer for syntax and rollout.

3. Security reviewer for permissions and servers.

4. Privacy reviewer for telemetry content.

5. Pull-request review requirements.

6. Validation and canary process.

7. Emergency rollback authority.

8. Review schedule and change log.

Protect the default branch and restrict who can change the source organization or repository.

Govern plugins and marketplaces

An approved marketplace is a distribution boundary, while an enabled plugin is executable capability. Review both publisher and package behavior.

Use managed controls to:

• Require or disable named plugins.

• Add approved internal or external marketplaces.

• Restrict discovery to known marketplaces.

• Pin versions through distribution controls where available.

• Prevent duplicate or abandoned package sources.

• Define team-specific exceptions with expiry dates.

• Record security contacts for every approved plugin.

• Remove packages whose owner or update process is unclear.

The Agent Plugins implementation guide explains packaging, compatibility testing, marketplaces, and update governance in more detail.

Build MCP server allowlists from capability review

Do not approve a server because its name sounds harmless. Inventory tools, side effects, authentication, network destinations, data categories, logging, and emergency disable behavior.

For each allowed server, record:

• Stable identifier, command, or URL used by policy.

• Publisher and internal service owner.

• Tools exposed and whether they change external state.

• Required filesystem, network, and credential access.

• User and tenant authorization checks.

• Sensitive output and log handling.

• Version and update process.

• Incident and revocation contact.

Use denied entries for known unsafe or conflicting servers, but keep the allowlist as the primary boundary. Test lookalike names, alternate URLs, and local command variants.

Configure telemetry with a privacy decision

Managed OpenTelemetry settings can standardize collector endpoint, protocol, service name, resource attributes, and content-capture policy. Observability is valuable for adoption, reliability, and incident investigation, but content capture may expose code, prompts, paths, or user data.

Define:

• The exact events and attributes required.

• Whether prompt or response content is collected.

• Environment and repository identifiers permitted.

• Redaction before export.

• Collector authentication and transport protection.

• Retention and access rules.

• Separation between security and productivity reporting.

• User notice and regional requirements.

Verify the applied configuration inside representative IDEs and at the collector. A valid policy file does not prove data is arriving safely.

Decide permission-mode controls

Disabling bypass approvals or autopilot can prevent agents from executing without expected confirmations. Match the restriction to repository and environment risk, and explain what developers should do when repeated approvals create friction.

Evaluate:

• Commands agents may execute by default.

• Paths they may read or change.

• Network requests and package downloads.

• Local secrets and production credentials.

• Destructive or irreversible operations.

• Approved sandboxes for unattended work.

• Exception process for controlled automation.

• Evidence retained after an approved bypass.

Policy should make safe work easier, not push teams toward unapproved tools. Use developer feedback to improve narrow capabilities while preserving boundaries.

Run a canary rollout

Select developers across several JetBrains products and operating systems. Include at least one team that uses plugins and one that uses an approved MCP server.

The canary should verify:

1. Authentication retrieves the intended managed policy.

2. Required plugins appear and blocked sources remain unavailable.

3. Allowed and denied MCP configurations behave correctly.

4. Telemetry reaches the approved collector with expected redaction.

5. Permission bypass controls cannot be overridden locally.

6. IDE performance and startup remain acceptable.

7. Developers can diagnose which settings are managed.

8. Rollback restores the last known policy.

Expand by team or organization rather than enabling every user simultaneously.

Measure coverage and exceptions

Report which users and clients receive policy, which version is active, and where enforcement is unavailable. A policy gap on an unmanaged device is an explicit residual risk.

Track:

• Active users under the managed baseline.

• IDE and plugin versions outside support.

• Blocked plugin and MCP attempts.

• Telemetry delivery and redaction failures.

• Permission override requests.

• Approved exceptions and expiry dates.

• Developer support issues.

• Policy changes linked to incidents or reviews.

Use the coding-agent governance guide to connect client settings with task routing, budgets, and evaluation evidence.

Frequently asked questions

Can developers override enterprise values?

Managed values take precedence for supported settings. Test this on every supported client and communicate which preferences remain local.

Should every MCP server be blocked initially?

An allowlist-first rollout provides a clear baseline. Approve required servers after capability and ownership review, then add time-limited exceptions through a documented process.

What if a policy change breaks development?

Use a canary, version the policy, keep a known-good revision, and assign an emergency owner who can revert safely. Preserve the failed configuration for investigation.

Explore Voquarn's enterprise AI governance services or book a managed-settings rollout review for a client-specific plan.