MCP Governance - Allow/Deny List for MCP for Organizations and Teams

El issue no especifica archivos, tests ni puntos de entrada. Empieza por localizar la ruta de solicitudes de herramientas MCP del lado del servidor y el modelo existente de autorización de organizaciones y equipos. La implementación debe cubrir los valores predeterminados de la organización, las excepciones específicas de los equipos, el comportamiento de las herramientas denegadas y los tests para los tres workflows descritos.

Feature Request: Allow and deny list for MCP Enterprises.

Describe the feature or problem you’d like to solve

GitHub Copilot's agentic features can leverage a powerful set of tools, including specific MCP Servers (e.g., "Azure MCP", "microsoft-docs", "playwright") and other extensions. While individual users can enable these tools locally, there is no centralized, enterprise-level control to enforce which tools are approved for use.

This creates a governance and security gap, as a user could enable and send data to an unvetted third-party tool. Furthermore, a single, organization-wide policy is too restrictive, as specialized teams (like QA or security) often require access to tools that should be denied to the general developer population.

Proposed solution

Implement a server-side MCP Server & Tool Governance Policy that is configurable at both the organization and team levels. This would allow administrators to set a baseline policy and grant specific exceptions for teams with elevated needs.

The workflow would be:

1. An administrator sets a default tool policy for the entire organization (e.g., "Deny by Default").
2. The administrator then creates more permissive policies for specific GitHub Teams (e.g., Allow the "playwright" tool for the @qa-engineers team).
3. When a user issues a prompt, the Copilot service checks the required tool against the policies that apply to that user, starting with their team-specific policies and then falling back to the organization default.
4. If an "allow" policy is matched, the request proceeds. If the tool is explicitly denied or not covered by an allow policy, the request is blocked and the user is notified.

This layered approach provides both a strong security baseline and the flexibility required for real-world enterprise operations.

Example prompts or workflows (for tools/toolsets only)

1. Workflow: Using an Approved MCP Server (Org-Wide)

   • An administrator has added "MCP Server: microsoft-docs" to the enterprise-wide allow list.
   • Any developer in the organization prompts: "Please research how to set up Azure Key Vault using the official Microsoft Docs."
   • The server-side check confirms the tool is allowed at the organization level, and the request is processed successfully.

2. Workflow: Attempting to Use a Denied MCP Server

   • The organization's default policy denies the "MCP Server: playwright" tool.
   • A developer who is not on the QA team enables it locally and prompts: "Generate a Playwright test script for my login page."
   • The server-side check finds the tool is denied by the default policy and no team-based exception applies. The request is blocked.
   • Copilot responds: "I am unable to use the 'playwright' tool as it is not approved for your team. Please contact your IT governance team for more information."

3. Workflow: Handling an Exception for a Specialized Team

   • The default policy denies the "playwright" tool, but the administrator has created a policy that allows it for the @qa-engineers GitHub Team.
   • A developer who is a member of @qa-engineers prompts: "Generate a Playwright test script for my login page."
   • The server-side check first sees the user is part of the @qa-engineers team and finds the corresponding "allow" policy for the "playwright" tool.
   • The request is approved and processed successfully, bypassing the organization's default denial.

Additional context

This feature is critical for applying realistic security and data governance policies. By managing tools with a combination of organization-wide defaults and team-based exceptions, enterprises can establish a secure baseline while empowering specialized teams with the advanced tools they need. The image below shows the exact type of tools that require this flexible, centralized governance.