GitHub Gives Admins an MCP Allowlist and an ROI Tab

GitHub shipped an MCP allowlist for enterprise Copilot on August 6, 2026, and it lands in the place governance features are supposed to land: the enterprise managed-settings file, not a per-developer preference. Enterprise owners can now name which Model Context Protocol servers Copilot clients are allowed to run — and, just as importantly, which ones they are not.

The mechanism is two new keys, allowedMcpServers and deniedMcpServers, added to copilot/managed-settings.json in the source organization’s .github-private repository and committed to the default branch. That is the whole control surface. It is deliberately unglamorous, and it answers “what can this coding agent reach?” with a file under review rather than a policy document.

This guide covers what the allowlist actually enforces and where it stops, the second and weaker MCP-restriction mechanism GitHub still runs alongside it, the impact dashboard’s new ROI section and the caveat GitHub attached to it, the usage-metrics API field that finally names individual agents, and the model launch the same week that shows why an admin-side control matters. Everything below comes from GitHub’s own changelog entries and documentation.

GitHub’s changelog entry states it plainly: enterprise owners can now centrally control which Model Context Protocol servers GitHub Copilot clients are allowed to run, using the new allowedMcpServers and deniedMcpServers keys in enterprise managed settings. The configuration is added to copilot/managed-settings.json in the source organization’s .github-private repository and committed to the default branch — which means the allowlist is a reviewable, diffable artifact with an audit trail, not a setting somebody flipped in a console.

Three matcher types decide what a rule applies to, and the third one carries a warning in GitHub’s own copy.

The failure mode matters as much as the matchers. GitHub says the policies fail closed, so a configuration that is malformed or cannot be verified blocks the connection rather than waving it through. That is the correct default for a security control and the opposite of how most developer-tooling config behaves, where a broken file usually means “ignore this and carry on.”

It is worth being clear about what this control is filling in. The Model Context Protocol specification is explicit that the protocol does not enforce security itself — session handling, consent, audience validation and server-trust decisions are left to implementers. The spec’s security guidance does list allowlists for trusted domains among the trust policies an authorization server can apply, though that passage is about client-side trust policy rather than an admin allowlisting servers, so it is a parallel rather than a precedent. GitHub is not duplicating a built-in protocol control here; it is closing a gap MCP deliberately leaves to the people deploying it. If you are building on the server side of that boundary, our MCP server security best practices guide covers the controls that sit underneath an allowlist.

Read the changelog entry alone and you would conclude that “MCP allowlists” is one feature. Read GitHub’s documentation and a second, older mechanism appears: a restriction based on the MCP registry, exposed as a registry-only style restriction, which GitHub’s docs label public preview and describe as not the recommended method for restricting access to MCP servers. The docs are unambiguous about which one to use — the recommended method for creating an allowlist is the enterprise’s managed-settings.json file.

The difference is not cosmetic. The registry-based mechanism matches on server name or ID only, and GitHub’s own reference page states that this enforcement can be bypassed by editing configuration files, and that strict enforcement preventing installation of non-registry servers is not yet available. That is a speed bump, not a boundary. The managed-settings mechanism is the one with URL canonicalization, exact stdio command matching and fail-closed behavior.

GitHub names the covered clients explicitly: the allowlist is currently enforced on the GitHub Copilot app, Copilot CLI and VS Code. Copilot runs in considerably more places than that — JetBrains IDEs, Eclipse, Visual Studio, Xcode, and GitHub’s own cloud agent among them — and the August 6 entry does not name any of them as enforcing this policy. The honest reading is that MCP servers reachable from an unenforced client remain reachable, whatever the allowlist says.

The older registry-based mechanism has its own compatibility matrix with per-client version floors — Copilot CLI from v1.0.11 and VS Code from v1.109.3, among others, with the Copilot cloud agent supporting neither display nor enforcement. Those floors belong to the preview mechanism, not the managed-settings one, and mixing them up in a compliance write-up is an easy mistake to make when both features share the phrase “MCP allowlist.”

The practical consequence is a scoping decision, not a blocker. An allowlist that covers three of your surfaces is worth having; a control map that claims it covers all of them is worse than having nothing, because it retires a risk on paper that is still live in production. Pair the allowlist with the same checks you would run on any server you connect — our 75-point MCP server security checklist treats an enterprise allowlist as one control among many rather than the answer.

A day after the allowlist, the Copilot impact dashboard gained a “Potential return on investment” section that connects what an organization spends on Copilot to the pull request output it gets back. The comparison it draws is the interesting design choice: it does not compare Copilot against no Copilot. It compares two adoption cohorts inside the same organization.

Three metrics appear on each card: cost per developer per month (the average monthly Copilot cost per developer in that group, derived from actual AI credit consumption), percentage of payroll per month (that cost expressed as a share of developer compensation), and pull requests per developer per month. A salary selector lets an admin pick a compensation band, and the cost-derived metrics recalculate instantly.

And then GitHub undercuts its own feature, in the same entry. The cost figures are described as estimates based on AI credit consumption; the salary selector is described as a modeling input rather than actual payroll data; and admins are told to treat the metrics as directional. That is a vendor shipping a spend-versus- output dashboard and simultaneously telling you not to over-trust it — which is unusually honest, and which means the dashboard is a reporting surface, not evidence of return.

The second August 7 change is smaller in the changelog and larger in practice: the Copilot usage metrics API now reports agent app activity, broken out by individual agent. Before this, third-party agent activity inside GitHub workflows was an aggregate. Now it has names.

The new field is totals_by_3rd_party_agent, an optional array with one entry per recognized agent app. Each entry carries a display name, a stable identifier, a count of agent-app job starts a user initiated, and — at aggregated report level only — a session count. GitHub explicitly recommends grouping on the stable identifier rather than the display name, because display names can change between periods and a report keyed on them will silently split one agent into two.

One distinction is easy to get wrong and worth stating outright: “agent app activity” here means third-party coding agents integrated into GitHub workflows — the changelog names agents from partners like Claude and Codex as examples — not Copilot’s own native agent mode. The word “agent” is doing at least three jobs across this release wave, and a metrics dashboard that conflates them will produce a number nobody can defend in a budget review.

Access to both the ROI section and the usage metrics is gated the same way: enterprise owners and billing managers, organization owners, and anyone holding a custom organization or enterprise role that grants the view-Copilot-metrics permission. That is a narrower group than the people who will be asked about the numbers, so plan for someone to export and redistribute.

On August 6, the same day as the allowlist, Kimi K3 became available in GitHub Copilot, hosted by GitHub on Fireworks AI and rolling out to Copilot Pro, Pro+, Max, Business and Enterprise across VS Code, Visual Studio, the Copilot CLI, the cloud agent, the Copilot app, github.com, GitHub Mobile, JetBrains, Xcode and Eclipse. That is close to every surface Copilot occupies.

The governance-relevant sentence is not about the model. GitHub states that Kimi K3 is off by default for Copilot Business and Copilot Enterprise, and that plan administrators must enable the Kimi K3 policy in Copilot settings before anyone in their organization can select it. A brand-new, third-party-hosted model arrived across an entire developer platform and organizations had to opt in rather than opt out.

On price, GitHub lists Kimi K3 in Copilot at $3 per million input tokens, $15 per million output tokens and $0.30 per million cached input tokens, billed at provider list pricing under usage-based billing. Two ratios fall straight out of those published rates and are worth internalizing before you enable anything: output costs five times what fresh input costs ($15 ÷ $3), and cached input costs one tenth what fresh input costs ($0.30 ÷ $3.00). A verbose agent loop is not expensive because it reads a lot; it is expensive because it writes a lot. We are not reviewing the model itself here — our hands-on look at Kimi K3 covers that. The changelog’s own capability framing is unaccompanied marketing copy on that page, so treat it as such.

There is a mirror image in the same window worth one sentence: when GitHub Code Quality reached general availability in July it silently created a ruleset that auto-requested Copilot review on every pull request, and on August 7 GitHub reversed that after feedback that adding a reviewer should be the team’s choice, disabling the auto-request settings while leaving manual Copilot review available. One agent defaulted off, another defaulted on and then off again. The industry is still calibrating what should be opt-in.

Most coverage of this window treats each change as a standalone item. Assembled under a governance lens they read as one release, and the useful column is the last one — what each change does not do. That column is where internal rollout docs go wrong, because a changelog headline is a capability claim and a control register needs a boundary. One row is not a change from this window: the older registry restriction sits in the table for comparison, because it is the mechanism the new allowlist is easiest to confuse with.

Look at the grouping rather than the rows. In two days GitHub shipped a restriction mechanism, two measurement surfaces, a default-off model policy, an explicit effort setting for automated review, a cap on inbound contribution volume, and a reversal of an agent that had been switched on without asking. That is not a feature wave. That is a platform discovering that the interesting questions about coding agents are no longer about capability — they are about reach, cost attribution and defaults. The same pattern is visible one layer up the stack, where the same supply-chain logic applies to skill packs.

The allowlist is a small file with large consequences, and the failure mode is not a broken build — it is a developer whose working setup stops working with no obvious explanation. Sequence it like any other fail-closed control.

The forward-looking read is straightforward. Enterprise controls for coding agents are converging on the same three primitives everywhere you look: an allowlist for what the agent can reach, a policy switch for which models are selectable, and a metrics surface that attributes spend to a named actor. GitHub now has all three; Cursor’s Organizations layer reached for the same shape from a different starting point. Expect the remaining Copilot clients to pick up allowlist enforcement, and expect the per-agent usage field to become the join key that finance teams use to allocate AI spend to teams the way they already allocate cloud spend.

The part that will not be solved by a vendor is the operating model around it — who owns the allowlist, how a developer requests an addition, what evidence a new server needs before it goes in, and how often the client-coverage list gets re-verified. That is governance design, not configuration, and it is the work we do with clients in our AI transformation engagements.