# interactive approval이 있는 local 작업에서만 Auto-review가 개입할 수 있다.
approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"

언제 reviewer가 개입하는가

main agent가 read-only 또는 workspace-write 안에서 작업하다 sandbox boundary를 넘어야 할 때 승인 요청이 생깁니다. 대표적으로 escalated shell/exec, 현재 정책이 막은 network request, writable root 밖 파일 편집, 승인 annotation이 있는 MCP·app tool 호출이 대상입니다. 새 website 또는 domain으로 Computer Use를 시도하는 경우도 승인 흐름에 포함될 수 있습니다.

approvals_reviewer = "auto_review"이면 그 요청은 사용자 팝업 대신 별도 reviewer agent로 갑니다. reviewer는 요청 자체와 필요한 대화·tool evidence를 보고 허용 또는 거절 이유를 돌려줍니다. 반대로 sandbox 안에서 이미 허용된 rg, workspace 내부 수정, 허용 network 요청에는 reviewer가 매번 붙지 않습니다.

Desktop app의 Computer Use 승인은 별도 사용자 승인 경로입니다. Auto-review가 켜져 있어도 화면 조작을 전부 대신 승인한다고 가정하지 말고, 해당 app prompt를 직접 확인해야 합니다.

승인·거절 뒤의 동작

허용되면 해당 경계 요청을 실행하고, 거절되면 main agent는 거절 근거를 받아 실질적으로 더 안전한 대안을 찾거나 작업을 멈추고 사용자에게 물어야 합니다. 같은 결과를 우회 명령, 간접 실행, 정책 회피로 다시 시도하는 것은 거절을 무력화하는 행동입니다.

Auto-review는 secret·credential을 신뢰하지 않은 목적지로 보내는 일, token·cookie 탐색, 광범위하고 지속적인 보안 완화, 되돌리기 어려운 파괴적 작업을 막는 쪽으로 설계되어 있습니다. 하지만 조직의 업무 승인권, 운영 데이터 변경의 사업상 맥락, 사용자가 허용한 예외까지 스스로 결정하지는 못합니다.

운영 credential을 사용한 배포가 필요하다.
1. Auto-review 거절을 여러 번 재시도하지 않는다.
2. credential이 없는 dry-run, 읽기 전용 조회, 별도 CI 승인 절차가 가능한지 먼저 찾는다.
3. 실제 배포가 남으면 대상 환경·변경 범위·되돌리는 방법을 적어 사용자에게 승인받는다.

선택과 운영 경계

개인 개발자가 모든 경계 요청을 확인해야 한다면 user가 적합합니다. 반복되는 low-risk escalation을 운영 중이고 sandbox가 충분히 좁다면 auto_review가 승인 대기 시간을 줄일 수 있습니다. 둘 다 on-request처럼 interactive approval이 있는 정책에서만 의미가 있습니다.