Copilot의 새 권한 관리, ‘항상 허용’보다 먼저 정할 것은 무엇일까요

핵심 요약 (TL;DR)

AI에게 명령 실행을 허용하는 일과, 팀 전체의 허용 범위를 정하는 일은 다릅니다. GitHub는 9월 9일 Copilot Business·Enterprise 관리자가 에이전트 작업을 중앙에서 차단하거나, 사람의 승인을 요구하거나, 확인 없이 허용할 수 있다고 발표했습니다.[1] 반복되는 승인창을 없애는 기능으로만 보기보다, 누구도 임의로 낮추지 못할 작업 기준을 만드는 변화로 읽을 만합니다.

이번 발표는 기존 승인 버튼과 무엇이 다른가요?

개인이 누르는 ‘항상 허용’은 당장의 번거로움을 줄입니다. 그러나 같은 프로젝트에서도 사람마다 허용한 작업이 다르면, 팀이 생각하는 안전선과 실제 실행 범위는 달라질 수 있습니다. 이번 관리 정책은 셸 명령, 파일 읽기·수정, 네트워크 도메인을 대상으로 하며, 사용자나 작업 공간 설정, 자동 승인, 저장된 승인으로 제한을 약화할 수 없다는 것이 공식 설명입니다.[1]

지원 범위도 확인해야 합니다. 발표가 일반 제공 대상으로 명시한 것은 Copilot 앱, Copilot CLI, Agent Host를 사용하는 VS Code 세션입니다.[1] 이름에 Copilot이 붙었다고 모든 편집기와 원격 에이전트에서 동일하게 작동한다고 가정해서는 안 됩니다. 팀에서 실제로 쓰는 클라이언트부터 목록으로 적는 편이 좋습니다.

작은 팀은 어떤 작업부터 나누면 좋을까요?

공식 설정에는 특정 작업을 막는 deny, 새 사람 승인을 요구하는 ask, 확인 없이 진행하는 allow가 구분돼 있습니다.[5] 이를 업무에 옮길 때는 금지 명령 목록을 길게 만드는 것보다, 실수의 결과를 먼저 생각해 보세요.

예를 들어 문의 접수 앱을 만든다면 테스트용 화면을 읽는 일과 실제 고객 연락처를 내보내는 일은 같은 권한이 아닙니다. 개발용 테스트 실행은 허용 후보로, 원격 저장소 반영은 승인 후보로, 업무와 관계없는 비밀 파일 접근은 차단 후보로 적어 볼 수 있습니다. 이 분류는 이 글의 운영 제안이며, 공식 설정 예제를 그대로 복사하면 모든 환경이 안전해진다는 뜻은 아닙니다.

테스트 명령도 내부에서 무엇을 실행하는지 검토한 뒤 허용하세요.

정책을 저장한 뒤에는 무엇을 확인해야 하나요?

설정 파일이 존재하는 것과 제한이 적용되는 것은 다릅니다. 실제 고객 데이터가 없는 별도 프로젝트에서 허용·승인·차단에 해당하는 무해한 행동을 하나씩 시험해 보세요. 허용 대상은 진행되는지, 승인 대상은 새 확인을 요청하는지, 차단 대상은 실행되지 않는지를 기록합니다. 위험한 삭제 명령으로 차단을 시험할 필요는 없습니다.

관찰 결과에는 클라이언트와 설정 배포 방식, 시험한 행동을 함께 남기세요. 새 팀원이 들어오거나 도구를 업데이트한 뒤 같은 확인을 반복하면, 문서에 적힌 정책이 실제 작업에서도 유지되는지 알 수 있습니다. 좋은 권한 관리는 에이전트의 속도를 일괄적으로 낮추는 일이 아니라, 멈춰야 할 순간만 정확히 남기는 일입니다.

FAQ: 개인 구독자도 같은 중앙 정책을 사용할 수 있나요?

이번 발표는 Business·Enterprise 관리자를 대상으로 합니다.[1] 개인 환경의 승인 설정과 기업 중앙 관리를 같은 기능으로 설명해서는 안 됩니다.

FAQ: 승인 규칙이 있으면 샌드박스는 없어도 되나요?

그렇게 단정할 수 없습니다. 공식 문서도 권한 규칙과 실행·파일·네트워크를 제한하는 sandbox 항목을 별도로 설명합니다.[5] 둘이 각자 어떤 행동을 제한하는지 확인하세요.

관찰 시점: 2026-09-11 KST

Sources

[1] https://github.blog/changelog/2026-09-09-enterprise-managed-permissions-for-github-copilot-agent-operations
[5] https://docs.github.com/copilot/reference/enterprise-administrators/enterprise-managed-settings