GitHub MCP allowlists, 6 August 2026: what platform teams must change now

Summary. On 6 August 2026 GitHub made allowedMcpServers and deniedMcpServers generally available in enterprise managed settings, giving enterprise owners their first central switch over which Model Context Protocol servers Copilot clients may run. One day earlier, on 5 August 2026, VS Code 1.132 removed the ChatAgentHostEnabled policy, so administrators can no longer disable the agent host that runs Copilot, Claude and Codex harnesses in a separate process. Both changes matter to the same person: whoever owns a managed IDE fleet. The allowlist covers 3 of the shipped Copilot clients and no JetBrains, Xcode or Eclipse install. GitHub's own reference page states the enforcement "can be bypassed by editing configuration files." At $19 per granted seat per month for Copilot Business and $39 for Copilot Enterprise, a 200-seat team is paying $7,800 a month for tooling whose connector policy is, by the vendor's description, advisory rather than enforced. This guide covers what shipped, what the matchers actually match, the 4 precedence layers, and the config to commit this month.

What GitHub shipped on 6 August 2026

The GitHub Changelog entry is short and precise: "Enterprise owners can now centrally control which Model Context Protocol (MCP) servers GitHub Copilot clients are allowed to run by using the new allowedMcpServers and deniedMcpServers keys in enterprise managed settings."

The keys live in a file, not a settings page. You add them to copilot/managed-settings.json in your source organisation's .github-private repository and commit to the default branch. That is the same delivery mechanism GitHub already uses for plugin standards and telemetry configuration, so most enterprises that have done any Copilot governance already have the repository.

Three things about the semantics are easy to get wrong on the first commit:

An unset allowedMcpServers allows every non-default server. An empty array blocks all of them, which is the deny-all posture. An unset or empty deniedMcpServers blocks nothing. And deny always wins: a server that matches deniedMcpServers is blocked even when it also matches allowedMcpServers.

GitHub also states that "Policies fail closed, meaning a malformed or unverifiable configuration is blocked rather than allowed. When policies come from multiple layers, a server must pass every layer." Fail-closed is the right default, but it has an operational consequence worth planning for: a bad commit to managed-settings.json does not degrade gracefully into the old behaviour. It blocks connectors for everyone on the next client sync. Treat that file like a firewall rule set, with review and a rollback commit ready.

The three matchers, and what each one is worth

Each key holds a list of matchers. There are three matcher types, and they are not equally trustworthy.

The serverName caveat is GitHub's, verbatim, and it sets the honest ceiling on this feature. If your threat model includes a developer who wants to run an unapproved connector, name matching does not stop them. If your threat model is an engineer who installs a plausible-looking community MCP server without thinking about it, name and command matching stops that fine.

The real cost is usually the inventory, not the config. Most platform teams do not yet have a list of which MCP servers their developers are running, and the allowlist gives them no discovery mechanism. You have to build that list first, from client configs, from the agentic audit log events GitHub exposes, or by asking.

GitHub says the allowlist is not a hard boundary

This is the part most coverage of the 6 August release left out. The MCP allowlist enforcement reference lists two limitations in plain language:

"Enforcement is based only on server name/ID matching, which can be bypassed by editing configuration files."

"Strict enforcement that prevents installation of non-registry servers is not yet available."

And then the recommendation: "For the highest level of security, you can disable MCP servers in Copilot until strict enforcement is available."

Read that as written. GitHub is telling security teams that if they need an actual boundary rather than a default, the supported answer today is to turn MCP off in Copilot entirely, not to write an allowlist. That is a legitimate posture for a regulated environment and a bad one for developer productivity, which is exactly the trade-off a platform team is paid to price.

There is a second control worth pairing with the file-based keys. Under enterprise or organisation settings, "Restrict MCP access to registry servers" offers two options, "Allow all" and "Registry only", against an MCP registry URL you supply. GitHub notes the registry URL and allowlist are in public preview and subject to change. If you point it at Azure API Center, enter the base URL including the workspace path, in the form https://SERVICE-NAME.data.REGION.azure-apicenter.ms/workspaces/WORKSPACE-NAME; adding a route suffix such as /v0.1/servers makes the registry error out, because Copilot appends the MCP v0.1 path itself.

For local stdio servers under "Registry only", the server must be in your registry with a server ID that exactly matches the installed server ID. Canonical IDs usually live in the server's documentation or manifest. Getting one character wrong silently blocks a connector your developers expect to work.

Four precedence layers, and which one wins

Enterprise managed settings resolve across four sources. Settings earlier in this list beat settings later:

1. MDM-managed settings

1. Server-managed settings

1. File-based settings

1. User-level settings

MCP allowlist policy resolves on a separate axis when a developer holds more than one Copilot seat. GitHub applies a single active policy and registry using three rules, in order: a parent enterprise policy overrides an organisation policy; Registry only beats Allow all because it is more restrictive; and where scope and strictness tie, the most recently uploaded registry wins.

That last rule deserves a note in your runbook. "Most recently uploaded registry wins" means a routine registry refresh in one organisation can change effective policy for contractors who hold seats in two. If you run a multi-org enterprise with shared vendors, set the policy at the enterprise level and stop maintaining org-level registries.

The control you lost on 5 August

VS Code 1.132, released 5 August 2026, removed an admin policy: "The ChatAgentHostEnabled policy is removed, so administrators can no longer centrally disable the agent host through policy. Developers can continue to use chat.agentHost.enabled to choose whether agents run in the separate agent host process."

The agent host is not a minor component. VS Code describes it as a process that "runs agent harnesses such as Copilot, Claude, and Codex in a dedicated process based on the Agent Host Protocol (AHP)." It is the mechanism by which third-party agent harnesses run inside a managed VS Code install. Until 1.132, an enterprise could switch it off centrally. From 1.132, the only remaining lever is a developer-side setting.

So the governance position for August 2026 is asymmetric: the connectors an agent can reach became centrally controllable, in preview, with a documented bypass; the question of which agent harnesses run at all stopped being centrally controllable in VS Code. Teams that built their agent host rollout plan on the 1.129 policy need to re-plan the fleet control, most likely at the extension-install layer or through MDM, which still sits above file-based settings in the precedence order.

One more 1.132 detail with a network dependency: the new multilingual dictation uses an on-device Nemotron 3.5 model that downloads on first use. If your build machines or developer laptops sit behind an egress allowlist, that download fails; VS Code offers a Foundry Local import path as the fallback.

Client coverage: where the allowlist actually applies

An allowlist that covers three clients out of a polyglot estate is a partial control, and it is worth being blunt about that internally before someone reports it upward as solved. If your Android and iOS teams live in JetBrains and Xcode, the 6 August release did nothing for roughly the half of your engineers who ship your mobile apps.

A managed-settings.json you can start from

The enterprise managed settings reference documents the file's shape for the keys that were already supported. As of 9 August 2026 that reference's "Supported keys" table lists permissions.disableBypassPermissionsMode, permissions.model, enabledPlugins, extraKnownMarketplaces, strictKnownMarketplaces, telemetry and remoteControl; the two MCP keys are documented in the changelog and the MCP how-to rather than in that table, which is normal for a preview feature. GitHub's published example configuration is:

            {
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "model": "auto"
  },
  "enabledPlugins": {
    "my-plugin@agent-skills": true
  },
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "OWNER/REPO" }
  ],
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true
  }
}
          

Two settings there do more for your risk position than the MCP keys will. disableBypassPermissionsMode set to "disable" stops users turning on bypass mode, which GitHub also calls YOLO mode, and which lets an agent run commands, access files and fetch URLs without asking for approval. An agent in bypass mode with an approved MCP server is a worse outcome than an agent asking for permission with an unapproved one.

The telemetry block is the other half. With enabled: true, an OpenTelemetry endpoint and lockCaptureContent: true, you get Copilot usage data in a collector you control while preventing users from switching prompt and response capture back on. Deploy that before the allowlist, because it is what tells you which servers are in use in the first place.

Two settings are overridable per enterprise team using the { "overridable": <VALUE> } syntax: permissions.model and permissions.disableBypassPermissionsMode. A team file can then set "model": "unmanaged" or "disableBypassPermissionsMode": "unmanaged" to take the specialisation. enabledPlugins and extraKnownMarketplaces work additively, so the enterprise file sets a baseline and a team file adds to it. Every other key stays an enterprise-level decision. If you are already using that mechanism for team-scoped model policy, the MCP keys sit alongside it without a new deployment path.

Why the vendor shipped this in August

MCP changed underneath everyone in late July. The maintainers finalised the 2026-07-28 revision on 28 July 2026, and Anthropic technical staff member David Soria Parra called it the "most substantial changes we have made to the specification, probably since adding authorization," adding that "a lot of things that made MCP are gone."

The headline change is the removal of protocol-level sessions, so each request is handled independently, with protocol version, client identity and capabilities travelling in the _meta parameter. Routing information is now mirrored in HTTP headers, which lets network equipment route requests without tracking session state or parsing the JSON-RPC body. Sampling and roots were deprecated; logging was told to use stderr, stdio or OpenTelemetry. Per Stacklok's readiness guide, features marked deprecated stay functional for at least 12 months, though that is not a guarantee of interoperability: servers on the 2026-07-28 revision may not work with older clients, and the reverse.

Scale explains the governance urgency. When Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI, the SDK was being downloaded more than 97 million times a month and at least 10,000 MCP servers had been set up.

Craig McLuckie, CEO of Stacklok and a co-creator of Kubernetes, framed the stateless move in enterprise terms to The Register: "This gives cyber teams a unified control point to apply agent aware policy and is delivered in a form factor that platform teams are comfortable with running."

A unified control point is the goal. What shipped on 6 August is the first version of it, and GitHub is candid that it is not yet strict. Both things are true at once, and the protocol choice underneath your agent estate determines how much of this control surface you get at all.

What to do this month

Work in this order. Each step produces something the next one needs.

1. Turn on Copilot telemetry to an OpenTelemetry collector with lockCaptureContent: true, and pull the agentic audit log events. Without usage data you are writing an allowlist from guesses.

1. Build the inventory. List every MCP server in use, per client, with its canonical server ID, remote URL or exact local command. Expect the JetBrains and Xcode entries to come from a survey rather than a query.

1. Set disableBypassPermissionsMode to "disable" before you touch the MCP keys. It is the higher-value control and it is fully supported, not in preview.

1. Start with deniedMcpServers, not allowedMcpServers. Deny wins, an unset allowlist changes nothing, and an empty allowlist array is a fleet-wide outage. Block the specific servers you have decided against, and watch for a week.

1. Prefer serverUrl matchers. Use serverCommand where you must, and treat serverName entries as labels rather than controls.

1. Decide the VS Code agent-host question explicitly now that ChatAgentHostEnabled is gone. If third-party harnesses are out of policy, enforce at the extension-install or MDM layer, which outranks file-based settings.

1. Write the rollback. managed-settings.json fails closed, so keep a known-good commit and a named owner who can revert it inside your incident SLA.

1. Re-check in 90 days. The registry URL and allowlist are in public preview and GitHub says both are subject to change.

India-specific considerations

For teams in India the sequencing question is sharper, because a remote MCP server is a data transfer, not a plugin. Once a Copilot agent can call a connector, prompt content, repository context and whatever the tool returns leave your boundary and reach whichever jurisdiction that server runs in. Under the Digital Personal Data Protection Act 2023, a data fiduciary stays accountable for personal data processed on its behalf, and "a developer installed it" is not a defence.

Three practical consequences follow.

First, serverUrl matchers are the only matcher type that tells you where data goes, which makes them the right default for any Indian entity with residency commitments in customer contracts. A serverName entry tells you nothing about the destination.

Second, the enforcement gap matters more here. Because GitHub says the allowlist can be bypassed by editing a config file, an allowlist alone is not evidence of a technical control for an audit. Pair it with egress controls on developer networks and the telemetry export, so you can show what actually ran rather than what policy said should run.

Third, GCC and services teams working for overseas clients frequently hold Copilot seats in more than one enterprise. Under GitHub's multi-seat resolution, the stricter policy and the most recently uploaded registry win, so a client's registry refresh can silently change what your engineers can run. Put registry ownership in the MSA rather than discovering it during a sprint. The wider agent governance layering question and the prompt-injection guardrails that sit under it are both prerequisites, not follow-ups, once connectors reach production systems.

Cost framing before you scope the work

The governance work here is a few days of platform engineering against a subscription line that is already five figures a month for a mid-sized team. That ratio is why the inventory step keeps getting skipped and why it keeps being the expensive one later.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based, ISO 27001:2022 certified engineering organisation, and our senior engineering teams work with platform and security groups rolling AI coding agents across mixed IDE estates. We design applications aligned with DPDP requirements, build the connector inventory and telemetry pipeline that makes an MCP allowlist meaningful, and set up the managed-settings deployment path with a tested rollback. If you are deciding how far to lock down agent connectors before your next audit cycle, talk to our engineering team and we will scope it against your actual client mix. Our wider work on enterprise AI agents in production covers the layers that sit underneath this decision.

References

1. MCP allowlists in enterprise managed settings - GitHub Changelog, 6 August 2026

1. MCP allowlist enforcement - GitHub Docs

1. Configure MCP server access for your organization or enterprise - GitHub Docs

1. Enterprise managed settings reference - GitHub Docs

1. Configuring enterprise-managed settings - GitHub Docs

1. MCP server usage in your company - GitHub Docs

1. Agentic audit log events - GitHub Docs

1. Visual Studio Code 1.132 release notes, 5 August 2026

1. Model Context Protocol prepares to break with its stateful past - The Register, 23 July 2026

1. MCP SDK betas for the 2026-07-28 revision - Model Context Protocol blog

1. Enterprise Readiness Guide for the July 2026 MCP Spec Update - Stacklok

1. Donating the Model Context Protocol and establishing the Agentic AI Foundation - Anthropic

1. Plans for GitHub Copilot - GitHub Docs

Last updated: 9 August 2026.