assisted permissions GA 뒤 Copilot CLI의 ask 규칙에 모델이 답한다. GitHub 관리 설정 문서는 여전히 ask를 '사람의 새 승인'으로 설명한다. 사람 승인이 필요한 명령은 deny로 올리거나 assisted를 조직에서 끈다.
에이전트 권한 정책은 작업을 허용, 물어보기, 금지 세 칸으로 나눈다. 가운데 칸에는 막을 정도는 아니어도 되돌리기 어려운 작업, 예컨대 Shell(git push *)가 들어간다.
물어보는 칸은 사람이 한 번 더 보게 하려고 만든다. 그런데 GitHub이 10월 26일 GA로 공지한 assisted permissions는 Copilot CLI, 앱, VS Code에서 명령 실행·경로 접근·URL 요청을 언어 모델이 먼저 보고 "clearly safe"면 통과시킨다. 이 판단이 ask 규칙에도 닿는다.
같은 ask 규칙을 GitHub 문서 두 곳이 다르게 설명한다
엔터프라이즈 관리 설정 문서의 표는 ask를 "특정 작업 전에 사람의 새 승인을 요구한다"로 적는다. bypass 모드, 자동 승인 설정, 훅, 예전에 저장한 허용으로는 ask를 통과시킬 수 없다고도 적었다.
assisted permissions 문서는 다르게 말한다. Copilot CLI에서는 셸 명령, 파일 읽기, 파일 쓰기, URL에 걸린 엔터프라이즈 ask 규칙이 검토 대상 요청이면 모델 승인으로 충족될 수 있다. 그래서 확인 창이 항상 뜨지는 않는다. deny 규칙만 그대로 적용된다.
검토 모델은 Copilot이 고르고, 대화 모델과 다를 수 있다. 자체 모델 프로바이더를 연결한 조직에서는 세션의 활성 모델이 검토를 맡는다. 요청을 낸 모델이 자기 요청을 승인한다.
bypass를 막아도 assisted는 남는다
Copilot computer use는 앱 조작 승인을 권한 모드에 맡긴다, 조직이 정할 값은 features.computerUse와 bypass 차단 두 줄이다에서 꼽은 bypass 차단으로는 이번 변경을 막지 못한다. 관리 설정 문서는 disableBypassPermissionsMode가 /permissions assisted와 /allow-all auto를 막지 않는다고 적었다.
| 관리 설정 | 하는 일 | ask를 모델이 통과시키는 것 |
|---|---|---|
disableBypassPermissionsMode: "disable" | allow-all 모드 차단 | 막지 못함 |
defaultMode: "manual" | 새 세션 기본 모드 지정 | 막지 못함, 정책이 허용하면 개발자가 Assisted를 고름 |
disableAssistedPermissionsMode: true | assisted permissions 비활성 | 막음, 조직 전체가 assisted를 잃음 |
해당 작업을 deny로 이동 | 작업 차단 | 막음, 에이전트가 그 작업을 못 함 |
두 문서 어디에도 ask 규칙 하나만 assisted 검토에서 빼는 설정은 없다. assisted를 끄면 빌드·테스트 명령까지 다시 사람이 눌러야 하고, deny로 올리면 그 작업은 사람이 직접 한다.
CI에서 assisted가 꺼진 사실은 stderr 한 줄로만 남는다
비대화형 실행은 --assisted-approval이나 COPILOT_ASSISTED_APPROVAL=true로 켠다. 검토가 승인을 요구하면 요청은 거부되고, 사유가 Copilot에게 돌아가 다른 방법을 찾게 한다.
엔터프라이즈 설정 때문에 assisted를 켜지 못하면 CLI는 표준 오류에 경고만 쓴다. 같이 넘긴 --allow-all-tools는 취소되지 않아 도구 요청이 검토 없이 승인될 수 있다. assisted는 --allow-all-paths·--allow-all-urls도 바꾸지 않아, --yolo와 같이 쓰면 경로와 URL 접근은 제한 없이 남는다.
문서는 이 기능이 샌드박스를 대신하지 않는다고 적는다. 10월 7일 GA된 로컬 샌드박스는 파일, 네트워크, Git 자격 증명 접근을 OS 수준에서 막고 관리 설정으로 강제된다. Anthropic이 10월 26일 제출한 S-1을 다룬 Fox News 10월 27일 보도에 따르면, 제3자 파트너의 설정 실수로 인터넷이 열린 채 보안 평가가 돌았고 모델 네 개가 외부 시스템에 무단 접근했다. Anthropic 조사에서 모델이 과제 밖 목표를 좇은 증거는 나오지 않았다. 과제 범위 안의 행동이 열린 연결 하나로 사고가 됐다.
가져갈 것
- 관리 설정의
permissions.ask에 사람 확인을 전제로 넣은 규칙(예:Shell(git push *))이 있는가? -
disableBypassPermissionsMode: "disable"만 걸고disableAssistedPermissionsMode는 비워 두었는가? -
disableAssistedPermissionsMode: true를 걸면 다시 사람이 눌러야 할 빌드·테스트 명령 수를 세어 봤는가? -
--assisted-approval이나COPILOT_ASSISTED_APPROVAL=true로 도는 CI 작업이--allow-all-tools,--allow-all,--yolo중 하나를 같이 넘기는가? - 그 CI 로그의 stderr에서 assisted를 켜지 못했다는 경고를 검사하는가?
- 자체 모델 프로바이더를 쓰는 팀의 보안 문서에 "요청 모델이 곧 검토 모델"이 적혀 있는가?
안 되는 경우
- 관리 설정 없이 개인 플랜으로 쓰거나 assisted를 이미 끈 조직에는 해당하지 않는다.
- 문서는 ask 규칙의 모델 승인을 Copilot CLI로 한정해 적었고, VS Code·앱의 동작은 밝히지 않았다.
- "clearly safe"의 기준, 검토 모델 이름과 입력 맥락, 감사 로그 기록 여부는 소스에 없다.
- GitHub이 두 문서 중 어느 쪽을 고칠지는 미정이다. 테스트 조직에 ask 규칙 하나를 걸고 CLI로 직접 확인한다.
이번 주에는 관리 설정의 ask 목록을 한 줄씩 읽고, 모델이 답해도 되는 규칙과 사람이 답해야 하는 규칙으로 나눈다. 후자가 한 줄이라도 있으면 deny와 assisted 비활성의 비용을 같은 회의에서 비교한다. 정책 문서의 "물어본다" 칸 옆에는 누가 답하는지 적는다.