MCP allowlist 운영법: 사내 Copilot에서 허용할 도구 서버를 통제하는 방법

검색 의도: MCP allowlist, GitHub Copilot managed settings, enterprise MCP 보안 핵심 요약: GitHub Enterprise managed settings에 allowedMcpServers와 deniedMcpServers가 추가되었다. 사내 AI 코딩 환경에서 MCP 서버를 자유 설치하게 둘지, 승인된 서버만 쓰게 할지 정해야 하는 팀에게 바로 필요한 보안 운영 기능이다.

MCP 서버는 작은 플러그인이 아니라 권한 경계다

MCP 서버는 에이전트에게 도구를 붙이는 가장 쉬운 방법이다. 파일 시스템을 읽고, 브라우저를 열고, Jira 티켓을 수정하고, 사내 DB를 조회하게 만들 수 있다. 문제는 이 편리함이 곧 권한 확장이라는 점이다. 개발자가 임의 MCP 서버를 추가하면 AI 도구가 접근할 수 있는 표면이 넓어진다.

GitHub는 2026년 8월 6일 changelog에서 Enterprise managed settings의 MCP allowlist 기능을 일반 제공한다고 밝혔다. enterprise owner는 copilot/managed-settings.json에 allowedMcpServers와 deniedMcpServers를 설정해 Copilot 클라이언트가 실행할 수 있는 MCP 서버를 중앙에서 제어할 수 있다.

지원 클라이언트는 GitHub Copilot app, Copilot CLI, VS Code다. 즉 개인 IDE 설정에만 맡기지 않고 조직 정책으로 도구 서버 목록을 관리할 수 있다.

allowed와 denied를 어떻게 나눌까

allowedMcpServers는 허용할 서버 목록이다. deniedMcpServers는 차단할 서버 목록이다. 둘 다 remote URL, local command, server name 기준 matcher를 지원한다.

실무에서는 allowlist 중심이 안전하다. AI 도구 생태계는 빠르게 늘어나고, 새 MCP 서버가 매주 나온다. denylist는 이미 아는 위험만 막는다. 반대로 allowlist는 검토한 서버만 열어둔다. 보안팀이 선호하는 fail closed 모델에 가깝다.

GitHub 설명에 따르면 정책은 fail closed로 동작한다. 설정이 malformed이거나 검증할 수 없으면 허용이 아니라 차단으로 처리된다. 여러 계층의 정책이 있을 때는 모든 계층을 통과해야 한다. 이 점은 중요하다. “설정 파일이 깨졌는데 우연히 전부 허용”되는 최악의 상태를 피할 수 있다.

matcher별로 주의할 점

serverUrl은 원격 HTTP/SSE 서버를 URL로 매칭한다. wildcard를 지원하고 URL canonicalization으로 우회 시도를 줄인다. 사내에서 운영하는 remote MCP 서버는 이 방식을 우선 쓰는 편이 좋다. 예를 들어 https://mcp.company.com/*처럼 조직이 관리하는 도메인을 기준으로 허용한다.

serverCommand는 로컬 stdio 서버를 command와 arguments로 정확히 매칭한다. 로컬 서버는 개발자 PC에서 실행되기 때문에 더 민감하다. 파일 접근, shell 실행, local credential 접근이 얽힐 수 있다. command path와 arguments까지 명확히 고정해야 한다.

serverName은 사용자가 붙인 label 기준이다. GitHub 문서도 편의용이며 보안 통제 수단으로 보지 말라고 한다. 사용자가 이름을 바꿀 수 있기 때문이다. 보안 기준에는 URL과 command를 쓰고, serverName은 운영자가 보기 좋게 정리하는 보조 정보로만 써야 한다.

사내 MCP 등록 프로세스 만들기

allowlist는 설정 파일만으로 끝나지 않는다. 등록 프로세스가 있어야 한다. 개발자가 필요한 MCP 서버를 제안하고, 플랫폼팀이나 보안팀이 검토하고, 통과한 서버만 managed settings에 들어가야 한다.

검토 항목은 복잡할 필요 없다. 최소한 다음을 본다.

• 서버가 어떤 데이터에 접근하는가
• write 작업이 있는가, read-only인가
• 인증 토큰을 어디에 저장하는가
• 로그에 민감정보를 남기는가
• 외부 네트워크로 데이터를 보내는가
• command 실행 권한이 필요한가
• 소스와 배포 주체가 신뢰 가능한가

이 체크리스트 없이 “유명한 MCP 서버니까 괜찮다”고 허용하면 나중에 사고가 난다. 특히 로컬 command 기반 MCP 서버는 사용자의 Git repository, .env, SSH key 주변에 접근할 가능성을 따져야 한다.

설정 파일 운영 패턴

GitHub는 source organization의 .github-private 저장소에 copilot/managed-settings.json을 추가하고 default branch에 commit하는 방식으로 시작하라고 안내한다. 이 저장소는 정책 저장소가 된다.

운영 패턴은 코드 리뷰와 비슷하게 가져가면 된다. MCP 서버 추가는 PR로 올리고, 보안 담당자나 플랫폼 담당자가 approve한다. 변경 사유, 서버 URL, command, 접근 범위, rollback 방법을 PR 본문에 남긴다. 이렇게 해야 나중에 “왜 이 서버가 열려 있지?”를 추적할 수 있다.

server-managed deployment에서는 두 key를 overridable로 표시해 팀별 allow/deny list를 baseline 위에 얹을 수도 있다. 이 방식은 중앙 통제와 팀 자율성 사이의 균형이다. 공통 차단 목록은 중앙에서 유지하고, 팀별 필요 서버는 각 팀이 추가하게 할 수 있다.

실행 체크리스트

• 현재 개발자들이 쓰는 MCP 서버 목록을 먼저 수집한다.
• remote URL, local command, server name을 분리해 표로 만든다.
• 보안 기준에는 serverName을 쓰지 않는다.
• 기본 정책은 allowlist 중심으로 설계한다.
• write 권한이 있는 MCP 서버는 별도 승인 단계를 둔다.
• .github-private/copilot/managed-settings.json 변경은 PR 리뷰로 관리한다.
• 정책이 fail closed로 동작할 때 개발 흐름이 멈추지 않도록 예외 요청 경로를 만든다.
• Copilot app, CLI, VS Code에서 정책 적용 여부를 실제로 테스트한다.

출처: GitHub Changelog, “MCP allowlists in enterprise managed settings”, 2026-08-06.