GitHub Copilot 로컬 샌드박스가 정식 출시되면 에이전트 권한부터 제한해보세요

로컬 샌드박싱은 무엇이고 어디에서 쓸 수 있나요?

Copilot이 사용자 컴퓨터에서 명령을 실행할 때 그 실행 범위를 제한하는 경계예요. GitHub 변경 기록에 따르면 Copilot CLI, GitHub Copilot 앱, 그리고 Agent Host를 쓰는 VS Code 세션에서 제공돼요. 격리에는 Microsoft eXecution Container(MXC)가 쓰이며, 하나의 샌드박스 정책을 Windows·macOS·Linux 각각의 운영체제 제어 기능에 맞춰 적용해요.

추가 비용 없이 Copilot에 포함된다고 해요. 어떤 요금제에서 쓸 수 있는지는 변경 기록에 적혀 있지 않았어요.

무엇을 제한할 수 있나요?

공식 문서가 설명하는 Copilot CLI의 제어 항목은 다음과 같아요.

자격 증명은 처리 방식이 독특해요. 샌드박스 안의 도구에는 대체 값만 전달되고, 실제 값은 로컬 프록시가 승인된 HTTPS 대상에게만 넘긴다고 문서는 설명해요. GitHub Copilot 앱은 이 가운데 파일 경로, 인터넷·로컬 네트워크, Git·GitHub CLI 자격 증명 여부만 노출하는 일부 항목을 제공해요.

확인일 2026-10-09, GitHub 공식 문서 기준이에요.

어떻게 켜고 무엇이 기본값인가요?

기본 상태는 꺼짐이에요. 켜기 전에는 Copilot의 셸 명령이 사용자 계정이 가진 접근 권한 그대로 실행돼요. CLI에서는 세션 안에서 /sandbox enable을 실행하면 이후 세션에도 유지되고, /sandbox disable로 꺼요.

적용 대상은 셸 명령, 파일 검색, 그리고 기본 설정에서는 로컬 MCP 서버와 언어 서버예요. 반대로 원격 MCP 서버는 샌드박스 대상이 아니에요. 외부 서비스에 연결하는 자동화라면 원격 서버 쪽 권한은 별도로 설계해야 해요.

운영체제마다 보호 수준이 같은가요?

같지 않아요. 문서에 적힌 차이를 운영체제별로 모으면 아래와 같아요.

macOS와 Linux에서는 프록시 설정을 무시하는 프로그램도 직접 접속하지 못해요. 반면 Windows에서 요청한 제한을 강제할 수 없으면 약한 제한으로 실행하지 않고 명령이 실패한다고 문서는 적어요.

조직은 사용을 강제할 수 있나요?

가능해요. 서버 관리형, MDM 관리형, 파일 기반 관리 설정으로 샌드박스를 요구하고 구성을 고정할 수 있어요. 변경 기록도 개발자가 약하게 바꿀 수 없는 정책을 기업 관리 설정으로 적용할 수 있다고 밝혀요.

관리 설정에서는 sandbox.enabled와 sandbox.failIfUnavailable 두 값이 언급돼요. 둘 다 참이면 샌드박스를 적용하지 못하는 환경에서 CLI가 모델 요청과 도구 실행을 막아요. 지원되지 않는 호스트에서는 failIfUnavailable이 함께 참이 아닌 한 서버 관리형 활성화 요청이 거절돼요. 또 정책이 우회를 허용하면 사용자는 현재 세션에 한해 끌 수 있고, 저장된 정책은 바뀌지 않아요.

도입 전에 어떤 한계를 알아야 하나요?

문서가 직접 밝힌 한계가 몇 가지 있어요.

• 가상 머신이나 컨테이너보다 가벼운 운영체제 수준의 격리예요. 보안 요구가 높다면 MXC 구현을 확인해 보라고 안내해요.
• 내장 파일 도구는 CLI 프로세스 안에서 돌아 운영체제 샌드박스가 보지 못해요. 이 도구들은 정책을 스스로 확인하며, 강제는 최선 노력 수준이에요.
• Linux의 bubblewrap은 셸 명령, 로컬 MCP·언어 서버 같은 하위 프로세스의 로컬 네트워크 접근을 따로 제어하지 못해요.
• 지원되지 않는 호스트에서는 CLI가 저장된 설정을 그대로 두고 그 세션만 끄며 알림을 띄워요.

모델과 도구 격리는 별개예요. 변경 기록은 어떤 모델을 쓰든 샌드박스 정책이 도구 실행에 똑같이 적용된다고 설명해요.

클라우드 샌드박스와는 무엇이 다른가요?

같은 문서에 클라우드 샌드박싱도 나와요. 이쪽은 GitHub가 호스팅하는 임시 Linux 환경에서 세션 전체를 실행하는 방식이며 공개 프리뷰 상태로 변경될 수 있어요. 조직 또는 엔터프라이즈 소유자가 Cloud Sandbox access 정책을 켜야 하고, 기본은 꺼짐이에요. 로컬은 내 컴퓨터에서 돌고 좌석에 포함되는 반면 클라우드는 사용량 기준 과금이라는 차이가 있어요. 이 글의 정식 출시 소식은 로컬 쪽에 해당해요.

에이전트 자동화에서는 어떤 순서로 적용하면 되나요?

먼저 읽기 전용 작업에 맞춰 허용 경로를 프로젝트 디렉터리 하나로 좁히고, 외부 통신은 필요한 호스트만 허용 목록에 올려 보세요. Git 자격 증명은 꼭 필요한 작업에서만 열어 두는 편이 나아요. 그다음 명령별 예외를 하나씩 늘려 가면 어떤 작업이 어떤 권한을 요구하는지 기록으로 남아요.

팀 단위라면 관리 설정으로 요구 수준을 정하기 전에, 지원되지 않는 개발 환경이 있는지부터 목록으로 만들어 두세요. 운영체제 버전에 따라 보호 수준이 달라지기 때문이에요.

최신 내용은 어디서 확인하나요?

GitHub Changelog의 2026-10-07 게시물과 GitHub Docs의 샌드박스 문서가 기준이고, 확인일은 2026-10-09예요. 설정 이름과 요구 조건은 바뀔 수 있으니 팀에 적용하기 전에 공식 문서를 한 번 더 열어 보세요.