코딩 에이전트의 로컬 저장소 권한, 작업 폴더만으로 충분할까요

로컬 코딩 에이전트에 프로젝트 폴더를 열어 주면 그 안의 파일만 다루리라고 생각하기 쉽습니다. 그러나 파일 접근 범위와 셸 실행, 네트워크 연결, 환경 변수와 자격 증명 접근은 서로 다른 권한입니다. 폴더를 지정했다는 사실만으로 컴퓨터 전체와 외부 서비스에 대한 접근까지 제한되었다고 보기는 어렵습니다.

GitHub는 2026년 10월 7일 Copilot의 local sandboxing 기능이 일반 제공 상태가 되었다고 공지했습니다. 제품별 세부 동작은 달라질 수 있으므로 여기서는 보안 경계를 설계할 때 확인할 질문을 정리합니다. 특정 설정을 직접 실험한 후기나 안전 보증으로 읽지 않도록, GitHub 공식 공지와 사용 중인 클라이언트의 현재 문서를 기준으로 판단해야 합니다.

파일 허용 범위와 실행 허용 범위를 나눕니다

에이전트가 저장소 파일을 읽을 수 있어도 임의 명령을 실행할 이유는 없습니다. 반대로 테스트를 실행하려면 셸 접근이 필요할 수 있지만, 그 명령이 홈 디렉터리나 다른 프로젝트까지 수정할 수 있어서는 안 됩니다. 파일 시스템 샌드박스와 명령 실행 정책이 각각 무엇을 허용하는지 확인해야 합니다.

권한 목록을 만들 때는 다음을 분리해 적어 보십시오.

• 읽기: 작업 저장소, 설정 파일, 홈 폴더의 민감 파일에 어디까지 접근하는가요?
• 쓰기: 변경 가능한 경로와 삭제 가능한 경로가 제한되어 있나요?
• 실행: 셸, 빌드 도구, 패키지 스크립트를 승인 없이 실행할 수 있나요?
• 통신: 어떤 호스트로 네트워크 요청을 보낼 수 있고 응답을 어디에 저장하나요?
• 비밀값: 환경 변수, CLI 로그인, 클라우드 자격 증명에 접근할 수 있나요?

에이전트가 소비하는 입력도 경계입니다

저장소에는 코드뿐 아니라 README, 이슈, 의존성 스크립트, 테스트 데이터처럼 지시문으로 오인될 수 있는 텍스트가 있습니다. 신뢰하지 않는 브랜치나 외부 기여자의 파일을 읽게 할 때는 해당 내용이 도구에 새로운 권한을 주지 못하도록 설계해야 합니다. 에이전트가 읽은 텍스트는 데이터일 뿐이며 보안 정책을 바꾸는 권한이 아닙니다.

패키지 설치 과정은 별도의 주의가 필요합니다. 설치 스크립트가 실행되면 에이전트의 파일·네트워크 권한을 그대로 사용할 수 있습니다. 필요한 의존성을 검토하고, 가능한 경우 잠금 파일을 사용하며, 외부 기여 PR에서 비밀값이 있는 CI 작업이 실행되지 않도록 기본 브랜치 정책을 확인하십시오.

첫 실행은 민감도가 낮은 저장소에서 합니다

설정을 문서만 읽고 안전하다고 추정하기보다, 민감하지 않은 테스트 저장소에서 허용 경계를 확인하십시오. 저장소 밖 파일 읽기와 쓰기를 요청했을 때 차단되는지, 네트워크가 막혔을 때 동작이 어떻게 바뀌는지, 허가되지 않은 명령이 승인 과정을 거치는지 관찰합니다. 테스트는 데이터가 없는 별도 환경에서 수행해야 합니다.

실행 전에는 테스트 자료만 준비하고 개인 토큰이나 실제 데이터는 두지 마십시오. 확인 결과와 사용한 클라이언트 버전을 기록한 뒤에야 실무 저장소로 옮기는 것이 낫습니다. 제품 업데이트로 정책이 바뀌면 같은 검증이 여전히 유효한지 다시 살펴야 합니다.

최소 권한은 매번 다시 줄여야 합니다

한 번의 테스트를 통과했다고 해서 늘 모든 권한을 허용할 필요는 없습니다. 문서 편집에는 네트워크가 필요하지 않을 수 있고, 테스트 실행에는 제한된 명령만 필요할 수 있습니다. 작업이 끝난 뒤 임시 토큰, 임시 파일, 승인된 권한이 남았는지도 확인하십시오. 작업 프롬프트에 허용 경로와 금지 작업을 명시하고, 예상 밖의 변경은 중단하도록 지시합니다.

개발자는 에이전트가 만든 코드를 검토할 뿐 아니라 에이전트가 실제로 사용할 수 있는 환경을 관리합니다. 조직 정책이나 고객 데이터가 얽힌 환경에서는 보안 담당자의 기준을 먼저 따르고, 개인 설정으로 예외를 만들지 않아야 합니다.

노트북과 개발용 가상 머신의 위험 수준은 서버 운영 환경과 다릅니다. 개인 프로젝트라고 해도 브라우저 세션이나 클라우드 자격 증명, 비공개 저장소 토큰이 같은 기기에 있을 수 있습니다. 실험용 계정과 분리된 저장소를 이용하고, 테스트 뒤에는 임시 권한을 회수하며, 실행 기록이 예상하지 않은 경로에 남지 않았는지 확인하십시오.

샌드박스 기능이 제공되는 제품이라도 OS별 동작과 지원하는 클라이언트가 같다고 가정하지 마십시오. 설정 화면의 현재 상태와 공식 문서에서 지원 범위를 읽고, 중요한 업데이트 후에는 최소한의 차단 시험을 다시 수행합니다. 정책이 적용되지 않는 환경이라면 실행을 보류하거나 격리된 환경을 마련하는 것이 안전합니다.

에이전트 권한은 사람의 편의를 위해 넓히기 쉽고, 한 번 준 권한은 작업이 끝나도 남을 수 있습니다. 예외 승인이 필요할 때는 승인 대상 명령과 목적을 확인하고, 일회성 허용인지 지속 허용인지 구분합니다. 지속 권한은 책임자와 만료 시점을 기록해 주기적으로 검토하십시오.

샌드박스는 개발 보안의 한 층일 뿐입니다. 악성 의존성, 취약한 테스트 도구, 권한이 과도한 CI 토큰을 모두 해결해 주지는 않습니다. 잠금 파일과 공급망 검사, 비밀값 접근 정책, 코드 리뷰 규칙을 함께 운영해야 합니다. 각 제어가 막는 위협과 막지 못하는 위협을 짧게 문서화하면 잘못된 안심을 줄일 수 있습니다.

개발 환경의 경계를 점검할 때는 에이전트에게 요청한 작업과 실제 접근을 비교하십시오. 의도한 파일보다 넓은 경로를 읽거나 예상하지 않은 명령을 실행하려 했다면 왜 그런 일이 발생했는지 조사하고 정책을 조정합니다. 테스트에서 확인한 범위와 확인하지 못한 운영체제·클라이언트 조합도 기록해야 결과를 과도하게 일반화하지 않습니다.

에이전트가 사용할 계정은 가능한 한 개발 전용으로 분리하십시오. 관리자 권한이 있는 기본 계정 대신 저장소에 필요한 권한만 가진 계정을 쓰면, 예기치 않은 명령이 실행되어도 영향 범위를 줄이는 데 도움이 됩니다. 계정 분리가 불가능하면 해당 세션에 비밀값이 노출되지 않도록 하는 조건부터 점검합니다.

마치며

로컬 저장소 경계는 폴더 이름 하나로 정해지지 않습니다. 파일 읽기·쓰기, 실행, 네트워크, 비밀값을 별도로 확인하고 저위험 환경에서 실제 차단 동작을 시험하십시오. 다음에 에이전트를 켤 때는 프로젝트 경로뿐 아니라 셸과 자격 증명의 범위도 함께 점검해 보시기 바랍니다.