When Agent Plugins 1.0 and MCP allowlists shipped in August, we noted a specific gap: the controls reached Copilot clients but not JetBrains, meaning a developer blocked from installing a plugin in VS Code could potentially install the same plugin elsewhere on the same machine. On 18 August, GitHub closed that gap.
Enterprise managed settings for Copilot in JetBrains now covers four areas that previously had no JetBrains-side equivalent at all.
The four controls
All four are set through managed-settings.json, the same file Business and Enterprise administrators already use for VS Code and the Copilot CLI:
- Plugin governance — enabledPlugins to auto-install or block specific plugins, extraKnownMarketplaces to add trusted sources, strictKnownMarketplaces to restrict installation to approved marketplaces only
- MCP server access — allowedMcpServers and deniedMcpServers, centrally controlling which MCP servers developers can reach, matching the allowlist mechanism that reached GA on 6 August
- OpenTelemetry configuration — collector endpoints, protocols, service names, resource attributes and content-capture policies, for organisations piping Copilot usage into their own observability stack
- Permission modes — permissions.disableBypassPermissionsMode, which prevents Bypass Approvals or Autopilot features from running unchecked
Why this closes a real gap rather than a cosmetic one
A policy that governs one client and not another is not a policy — it is a suggestion with an escape hatch. Anyone in your organisation using JetBrains rather than VS Code was, until 18 August, operating outside every plugin and MCP control your admin console enforced elsewhere.
That mattered more than it might have two months ago, because two features shipped this month specifically expand what an agent can reach: Agent Plugins 1.0 on 12 August made installing bundled capability a one-click action, and Copilot memory arrived in JetBrains on 11 August with unclear scoping around what gets retained. A governance gap on the exact platform that gained new capability and new statefulness in the same fortnight was the wrong gap to have open.
The bypass permissions control deserves particular attention
permissions.disableBypassPermissionsMode is the one item on this list that is not about reach but about restraint. Bypass Approvals and Autopilot features let an agent act without per-step confirmation — useful for velocity, and precisely the setting an organisation with change-control requirements needs a way to switch off centrally rather than trust to individual discretion.
If your organisation has a policy about unattended agent actions in VS Code, it almost certainly did not extend to JetBrains until this week. Check whether it now needs to.
What is still unstated
GitHub's post refers to "JetBrains IDEs" without naming which ones specifically get this — treat it as the full IDE family until you have confirmed otherwise for the one you run.
It also does not explicitly connect this release to the memory and Ollama features from 11 August, though the practical effect is that both are now governable rather than left to individual settings. If you audited permissions after that release and found nothing to configure, it is worth another look now.