# GitHub Copilot Enterprise Management Arrives in JetBrains IDEs

- Link: https://thestackobserver.com/github-copilot-enterprise-management-arrives-in-jetbrains-ides/
- Published: 2026-08-19T08:46:48-04:00
- Author: Stackxx

By mid-2026, most engineering organizations have at least one AI coding assistant
running inside their developers’ IDEs. Some teams adopted these tools as fast as
they adopted Slack. Others dragged their feet, watched competitors ship faster, 
and eventually gave in. Very few had a governance plan ready before the first agent
started suggesting code that touched production secrets.

The problem is not the AI itself. It is that the configuration lives in the client,
invisible to security teams, and changes every time a developer installs a plugin
or connects to an MCP server they found on Reddit. A JetBrains IDE with GitHub Copilot
can communicate with dozens of external services, execute generated code against
internal APIs, and ship telemetry to endpoints the security team has never audited.
If your organization runs Copilot in JetBrains and you cannot answer yes to all 
of the following, you are carrying material governance risk:

 * Do we know which Copilot plugins are installed?
 * Do we know which MCP servers developers are connecting to?
 * Is Copilot telemetry going to our collector, or someone else’s?
 * Can the Copilot agent autonomously approve its own PRs without a human in the
   loop?

GitHub answered that question on August 18th, 2026, with the release of **enterprise
managed settings** for GitHub Copilot in JetBrains IDEs. The feature gives administrators
centralized control over plugin governance, MCP server access, OpenTelemetry configuration,
and agent permission modes. For platform and DevOps teams, this is the first practical
mechanism to treat AI-assisted development as a governed, auditable service rather
than a free-for-all in the IDE.

## What Can Now Be Governed

The new settings surface four distinct control planes, each targeting a different
class of risk. They are applied at the enterprise level and override whatever a 
local developer has configured in their IDE.

### Plugin Governance

Copilot plugins in JetBrains can range from harmless utilities to agents that read
internal databases. The enterprise-managed plugin governance settings give administrators
three levers:

 * **enabledPlugins** — Require specific plugins to be enabled, or block plugins
   from being active. This is useful when your team depends on a critical internal
   tool or wants to disable something known to be problematic.
 * **extraKnownMarketplaces** — Define approved plugin sources beyond the default
   JetBrains marketplace. If your organization hosts an internal plugin repository,
   you can make it available without leaving the default marketplaces uncontrolled.
 * **strictKnownMarketplaces** — Restrict plugin installation to a specific allowlist
   of marketplaces. This prevents developers from installing plugins from untrusted
   or external sources.

For security teams, this solves a classic shadow-IT problem: a developer finding
a Copilot-augmented plugin on a third-party marketplace and installing it on a machine
with access to production credentials. Before this release, there was no practical
way to prevent that centrally.

### MCP Server Allowlists

The **Model Context Protocol (MCP)** is how AI agents connect to external tools,
databases, and APIs. Every time a developer adds an MCP server to their Copilot 
setup, they are granting an AI agent permission to query, modify, or act on systems
outside the IDE. Some MCP servers are benign. Others are wrappers around production
databases, CI pipelines, or cloud provider APIs.

The new `allowedMcpServers` and `deniedMcpServers` controls give administrators 
a centralized allowlist and denylist for MCP servers accessible from Copilot in 
JetBrains. This closes a gap that has concerned security teams since MCP adoption
accelerated: the ability for an AI agent to silently establish connections to external
systems with no audit trail and no approval process.

The practical implication is that platform engineers can now define which MCP endpoints
are appropriate for each environment. A developer in a regulated environment cannot
accidentally—or deliberately—connect to an unauthorized MCP server that has access
to production data.

### Managed OpenTelemetry

Copilot generates telemetry: what prompts are submitted, what responses are generated,
what context is collected, and how long interactions take. Where that telemetry 
goes is not a technical detail—it is a compliance question. If your organization
falls under GDPR, CCPA, HIPAA, or any industry-specific regulation, uncontrolled
telemetry routing can create audit failures and legal exposure.

The managed OpenTelemetry settings let administrators centrally configure the collector
endpoint, protocol, service name, resource attributes, and content-capture policy
for Copilot telemetry in JetBrains IDEs. Managed values take precedence over anything
a developer configures locally, so telemetry is consistently routed to the approved
collector without relying on individual compliance.

Developers can review the applied configuration in the IDE under _Settings > Tools
> GitHub Copilot > Chat > OpenTelemetry_, making the policy both transparent and
verifiable.

### Permission Modes

Copilot has been evolving toward autonomous action. Features like **Bypass Approvals**
and **Autopilot** allow the AI agent to take actions—approve pull requests, merge
code, trigger deployments—without a human signing off. This is the fastest way to
ship. It is also the fastest way to ship a production incident.

The new `permissions.disableBypassPermissionsMode` setting lets administrators disable
these autonomous modes organization-wide. When set to `disable`, the Copilot agent
in JetBrains cannot use Bypass Approvals or Autopilot, forcing a human review step
for every action.

For regulated industries and any team running production systems, this is probably
the most immediately valuable control in the release. The value of AI-assisted development
drops to zero if the AI has permission to break production without oversight.

## How Platform Teams Should Implement This

Enterprise managed settings are configured through GitHub’s enterprise management
API, not through the IDE itself. This is important for a few reasons: the settings
apply to everyone on the enterprise plan, they override local IDE preferences, and
they can be versioned and audited like any other infrastructure policy.

Here is a practical implementation sequence for platform and DevOps teams:

 * **Inventory what is already out there.** Before writing policies, survey your
   developer population. Which Copilot plugins are installed? Which MCP servers 
   are configured? Where is telemetry going today? You cannot govern what you do
   not know exists.
 * **Start conservative with MCP servers.** Default to deny-all and add only explicitly
   approved MCP endpoints. This is easier than retroactively discovering that someone
   connected a production database MCP server six months ago.
 * **Route telemetry to your existing observability stack.** If you already run 
   an OpenTelemetry collector for application traces, point Copilot telemetry there.
   Do not create a separate shadow pipeline for AI-generated telemetry.
 * **Disable autonomous permission modes unless you have a compliance framework 
   for them.** Autonomous AI actions in production require change management, rollback
   procedures, and audit trails. If you do not have those, disable the feature.
 * **Communicate the policy before enforcing it.** Developers will notice when their
   favorite plugin stops working. A proactive communication with a migration path
   and a support channel prevents policy from being perceived as punishment.

## What This Does Not Fix

Enterprise managed settings are a control mechanism, not a security guarantee. They
constrain what Copilot can do, but they do not validate the safety of the code Copilot
generates. A developer with a locked-down Copilot instance can still prompt the 
AI to suggest code that contains injection vulnerabilities or hardcodes secrets.
Governance and static analysis remain separate concerns.

The controls also apply only to GitHub Copilot in JetBrains. If your developers 
also use VS Code, Cursor, Zed, or other AI coding assistants, this policy does not
cover those. Multi-IDE governance remains a gap that most organizations have not
solved.

Finally, the settings require an enterprise Copilot plan. Individual and team plans
do not support centralized management. If your organization is on a lower tier, 
this feature is not available, and the governance burden falls on endpoint management
or manual enforcement.

## The Bigger Picture: Control Planes for AI-Assisted Development

The release of enterprise managed settings for Copilot in JetBrains fits into a 
broader trend: the tooling industry is building control planes for AI-assisted development.
Platform engineering teams are increasingly asked to treat AI tools not as magical
developer productivity enhancers, but as infrastructure components that need governance,
observability, and compliance.

GitHub’s move here is notable because it treats the IDE as a governance surface.
The IDE was historically a developer-owned space, invisible to platform teams. By
adding enterprise-level controls that override local preferences, GitHub is acknowledging
what many platform engineers already know: the IDE is infrastructure, and infrastructure
needs policy.

For organizations that have been waiting for a practical way to govern AI-assisted
development without blocking it entirely, this is a meaningful step forward. It 
gives platform teams a starting point—four clear control levers they can implement
today, with a path toward more nuanced policies as the tooling matures.

## Sources

 * [Enterprise managed settings in GitHub Copilot for JetBrains](https://github.blog/changelog/2026-08-18-enterprise-managed-settings-in-github-copilot-for-jetbrains/)—
   GitHub Changelog, August 18, 2026
 * [Enterprise managed settings reference](https://docs.github.com/copilot/reference/enterprise-managed-settings-reference)—
   GitHub Documentation, 2026
 * [GitHub Copilot’s Latest Update Bets on Model Choice, Not Model Loyalty](https://devops.com/github-copilots-latest-update-bets-on-model-choice-not-model-loyalty/)—
   DevOps.com, August 17, 2026
 * [The Rise of Control Planes: How Platform Engineering Is Securing AI-Driven Infrastructure](https://thestackobserver.com/the-rise-of-control-planes-how-platform-engineering-is-securing-ai-driven-infrastructure/)—
   The Stack Observer, August 10, 2026