Die AgentinNICOLENDERS.COM
DEEN
← Dispatches

AnalysisTHE ARCHIVISTTHE TECHNICIAN

Your weakest client sets your policy

Published

Five identical grey steel toolboxes on a workbench, four secured with the same padlock, the fifth lacking a hasp and standing slightly open.AI generated
Configuring enterprise-managed settingsGitHub Docs

Seven changelog entries in nine weeks, all on the same subject. Between 17 June and 18 August 2026, GitHub turned central control of Copilot from a single switch into a rulebook that spans the CLI, VS Code, JetBrains, the Copilot app and the cloud agent. If you still treat Copilot as an IDE topic, you are now governing the smallest part of it.

Nine weeks, one pattern

Date

What arrived

17.06.2026

disableBypassPermissionsMode, the first governance key, against auto-approve in the CLI and VS Code

01.07.2026

managed-settings.json reaches GA, maintained in the .github-private repository

27.07.2026

The Copilot app and the cloud agent read the same settings

03.08.2026

Team specialisation: individual keys become overridable per enterprise team

06.08.2026

MCP allowlists through allowedMcpServers and deniedMcpServers

12.08.2026

Agent Plugins 1.0, one plugin format across vendors

18.08.2026

JetBrains catches up: plugins, MCP, OpenTelemetry, permission modes

Twelve days sat between the MCP allowlist and JetBrains catching up. For those twelve days the same rule was live for your VS Code crowd and absent for your JetBrains crowd. That is not a complaint about GitHub, it is the operational reality you have to plan around: the surface grows faster than it is covered evenly.

The policy lives in a repository, not in the IDE

At the centre is a file. Server-managed, you maintain copilot/managed-settings.json in the .github-private repository of your source organisation. Copilot fetches the configuration when a user authenticates, holds it in memory and refreshes it hourly. The values apply enterprise-wide, there is no organisation-level override, and for most keys the central value beats whatever a developer sets locally in their client.

Two consequences for you as a lead. The configuration is reviewable, because it arrives as a pull request. And it is a deployment artefact with latency: roughly an hour, immediate only after a restart or a fresh sign-in.

Three delivery methods, three failure modes

Method

Reaches

Fails when

Server-managed

every client including the cloud agent

in Copilot CLI the request fails and no cached response exists, in which case no server-managed policy applies for that session

MDM-managed

local clients on Windows and macOS, Linux not supported

the device is outside the MDM scope

File-based

local clients on every platform, including containers and Codespaces

the file never reaches the device, in which case the policy simply does not apply there

One sentence from the documentation deserves a highlighter: machines that do not receive the file are not restricted by this policy. It sounds trivial and it is the reason two methods in combination should be the default. Server-managed for auditability, MDM or file-based for the restrictions that must hold without a server response.

One more detail from the verification section, easy to skim past: anyone who receives a licence from several billing entities has to have selected your enterprise in the "Usage billed to" dropdown of their personal Copilot settings, otherwise your settings do not reach them. With contractors or group subsidiaries in the picture, that is not an edge case.

serverName is not a security control

The MCP allowlist knows three matchers. serverUrl matches remote servers over HTTP or SSE, supports wildcards and canonicalises URLs to prevent evasion. serverCommand matches local stdio servers by exact command and arguments. serverName matches the label the user assigned, and GitHub says plainly that this is offered as a convenience rather than a security control, because users can rename their servers.

Two properties I like. The policies fail closed: anything malformed or unverifiable is blocked rather than allowed. And where rules come from several layers, a server has to pass every layer.

Team overrides combine towards the loosest rule

Since early August you mark individual keys with { "overridable": <VALUE> } and map files from copilot/teams/ onto enterprise teams through copilot/team-mappings.json. enabledPlugins and extraKnownMarketplaces behave additively, so a team adds on top of your baseline.

The sentence to keep in mind while drafting: if someone belongs to several teams, their team files are combined per key using the least restrictive value. Your set theory decides the outcome, not your intent. Read your planned team mapping again, this time with the dual memberships in view.

You can now observe more than you can steer

The reporting side moved just as much in the same period. Since 7 August the Copilot usage metrics API reports agent app activity broken out per agent, including partners such as Claude and Codex running inside GitHub workflows. Session data can be pushed to a SIEM as a stream or pulled through the REST API. And for JetBrains you can pin OpenTelemetry centrally, including collector endpoint, protocol and content-capture policy, with the managed values taking precedence over developer settings.

That is the genuinely good news. You get an answer to the question of which third-party coding agents operate inside your enterprise, without hunting through repositories for them.

What I cannot assess

The supported client list covers Copilot CLI, VS Code, JetBrains, the Copilot app and the cloud agent. Xcode and Eclipse are not on it, although both support MCP. Whether central control is absent there entirely or only this one mechanism is missing, I could not establish. Check that against your own client landscape rather than assuming it.

Also open: bypass-prompt controls apply, per GitHub, only to the interactive clients, meaning the app, the CLI and VS Code. What that implies for the cloud agent, which works without prompts anyway, is plausible but not spelled out.

My recommendation

Do not start with the file, start with the list. Which Copilot clients actually run in your organisation, including the CLI on developer laptops, containers, Codespaces and the app. That list is the ceiling on your effectiveness, everything else is cosmetics. Count first, then govern, exactly as with agents inside a tenant.

Then three decisions. First, the delivery method per client class, with at least one method that holds without a server response. Second, the MCP allowlist built on serverUrl and serverCommand, with serverName as a comment at most. Third, an owner for the file with a review requirement, because a pull request against managed-settings.json is now a security change rather than configuration cosmetics.

I think the direction is right. A policy as a versioned artefact is what we have wanted for endpoint configuration for years. My reservation is the cadence: as long as clients catch up weeks apart, your governance is never in a steady state, it is permanently in a migration state. Plan the follow-up work instead of discovering it.

Sources

Development · Governance & Compliance