An organization wants to allow teams to use approved MCP servers but prevent agents from connecting to arbitrary or untrusted external MCP servers. Which configuration approach achieves this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A corporate travel policy doesn't say 'call us before every flight' — it says 'here's the list of approved airlines.' An MCP allowlist works the same way: approved servers are pre-vetted, developers can use them freely, and anything not on the list is blocked at the system level.
Full explanation below image
Full Explanation
Organizations using GitHub Copilot agents at scale need a governance mechanism for MCP server usage. An organization-level registry with an allowlist is the standard approach.
Why B is correct: An organization-level MCP registry allows security and platform teams to vet and approve specific MCP servers. Developers can connect to any server on the allowlist without additional review. Connections to servers not on the allowlist are blocked by policy. This balances security control with developer productivity.
Why A is wrong: Manual review before each agent run is operationally unsustainable at scale. It introduces human bottlenecks and inconsistency. Policy-based allowlists are faster and more reliable.
Why C is wrong: Disabling all MCP server support eliminates the risk but also eliminates the capability. MCP is a core mechanism for extending agent functionality, and a blanket ban prevents legitimate use cases. The goal is governed access, not no access.
Why D is wrong: Trusting all MCP servers by default is a security anti-pattern. A malicious actor could host an MCP server that exfiltrates data or performs unauthorized actions. Network firewalls operate at the IP/port level and cannot make security decisions based on the content or legitimacy of MCP server implementations.