Anyone can claim to be an electrician. A serious site doesn't let a stranger plug gear into the panel just because they showed up — there's an approved-contractor list at the gate. Two things make it work: a directory of vetted contractors (names, licenses, what they're cleared to do), and a gate rule — "only people on the list get in," or the looser "anyone's welcome."
For MCP, that directory is a registry, and that gate rule is an allow list. Lesson 2.3 was how to plug in a server; 2.4 is who's even allowed to — set by an admin, above the individual developer.
The idea, in plain English
MCP has three parts worth naming (a likely exam beat):
- Server — provides the tools/context (lesson 2.3).
- Registry — a catalog of approved servers (the directory at the gate).
- Allow list — the access-control policy deciding which servers may actually be used (the gate rule).
Configure the MCP registry (point Copilot at a catalog) and configure MCP allow lists (set which servers are permitted). This is an org/enterprise governance control — not something an individual agent file decides.
Configuring the registry + the allow-list policy
An admin:
- Enables MCP — "MCP servers in Copilot" must be Enabled (org) / Enabled everywhere (enterprise).
- Sets the MCP Registry URL — a catalog of approved servers (creating the registry is a prerequisite to setting access policy). Backing store can be Azure API Center (
https://SERVICE.data.REGION.azure-apicenter.ms/workspaces/WORKSPACE). Trap: don't append/v0.1/servers— Copilot adds it automatically. The GitHub MCP Registry is atgithub.com/mcp. - Sets the access policy — the "Restrict MCP access to registry servers" dropdown:
| Policy | Meaning |
|---|---|
| Allow all | no restriction — any MCP server is usable |
| Registry only | only servers listed in the registry may be used (stricter) |
Saved policy takes effect immediately for all developers in scope. The policy that applies to a developer comes from whichever org/enterprise granted their Copilot seat. (Feature is in public preview.)
Which policy wins (memorize the order)
When more than one policy could apply, GitHub resolves in this order:
| Step | Rule |
|---|---|
| 1 · Scope | Enterprise beats org (enterprise rules cover every org/user under it) |
| 2 · Strictness | Registry-only beats Allow-all (the more restrictive wins) |
| 3 · Recency | on ties, the most recently uploaded registry wins |
And if a user holds seats from multiple orgs/enterprises, GitHub applies one policy — it does not combine them.
A developer has seats from Enterprise X (Registry-only) and Org Y (Allow-all). Step 1 scope: enterprise outranks org → Enterprise X wins → the developer is held to Registry-only. (Even at equal scope, step 2 strictness would still pick Registry-only.) One-look: enterprise > org; stricter > looser; newer > older — in that order, one policy at a time.
The honest limitation (exam-worthy)
The allowlist is not tamper-proof today:
- Enforcement only checks the server name/ID; a local user editing config files can work around it.
- There's no hard-block that prevents installing a non-registry server yet — a known gap.
- For maximum security right now, fully disable MCP servers rather than trusting the allowlist.
- Under Registry-only, even local servers must be in the registry, with an exact ID match (check the server's docs/manifest).
Treat allow-list changes as governance-sensitive — review them like high-risk dependency changes. Wildcard allow-lists are an anti-pattern; pair registry policy with the narrow per-tool allow-listing from 2.2 (github/<tool>, not github/*).
The cert-language version
Which MCP servers an agent may use is governed by registries (a catalog of approved servers) and allow lists (the access policy) — set at the org/enterprise level, not in the agent file. The policy is Allow all or Registry only, resolved by scope (enterprise > org) → strictness (Registry-only wins) → recency. Enforcement is name/ID-based and not tamper-proof; for maximum security, disable MCP entirely.
Our summary · grounded in MS Learn — Agent tooling… + GitHub Docs (configure MCP registry/access, policy resolution) + MS Reactor 2026-05-28 · fetched 2026-05-30
Common confusions (read these or lose points)
- "The agent file decides which MCP servers are allowed." No — that's an admin registry/allow-list policy at org/enterprise level.
- "Allow all = secure default." No — Registry-only is the restrictive one; Allow-all permits any server.
- "Org policy can override enterprise policy." No — enterprise beats org; and the stricter policy wins on ties.
- "The allowlist hard-blocks bad servers." Not yet — it checks name/ID and is bypassable by editing config; for real lockdown, disable MCP.
- "Registry-only only applies to remote servers." No — local servers must also be in the registry, with an exact ID match.
Ticks this lesson done on the home roadmap. Saved in this browser.