자동 검토는 검토 대상인 승인 요청을 별도의 검토 에이전트에 전달합니다. 어떤 작업에 승인이 필요한지는 샌드박스, 명령어 규칙, 도구 설정에 따라 달라집니다. 해당 작업을 진행할 수 있는지는 검토 에이전트가 판단합니다.
자동 검토는 대화형 승인 정책을 사용할 때만 적용됩니다. approval_policy = "on-request"를 사용하거나, 해당 유형의 승인 요청을 표시하도록 세분화된 승인 정책을 설정해야 합니다. approval_policy = "never"이면 검토할 요청이 없습니다.
ChatGPT 데스크톱 앱에서 승인된 Daybreak 모델을 선택하면 권한 모드가 자동으로 대신 승인 모드로 전환됩니다. 이 모드를 계정에서 사용할 수 있고 조직 정책에서도 허용할 때만 전환됩니다. 데스크톱 앱의 /model 명령어로 모델을 선택할 때도 마찬가지입니다. 이 모드를 사용할 수 없으면 현재 권한 모드가 유지됩니다. 모델을 선택해도 조직에서 관리하는 요구 사항이 항상 우선합니다.
ChatGPT 데스크톱 앱은 승인된 보안 모델에 전체 권한을 부여하기 전에 위험한 작업에 관한 모델별 경고를 표시합니다. 경고에서는 대신 승인 모드를 권장하고 검토 정책 설정 링크를 제공합니다. 경고가 표시되어도 샌드박스 경계가 복원되거나 조직 정책이 무효화되지는 않습니다.
자동 검토 선택
데스크톱 앱에서 메시지 입력창 아래의 권한 메뉴를 열고 대신 승인을 선택하세요. 현재 채팅에 이 모드가 선택되어 있는지 확인하세요. 모드 선택 방법과 문제 해결 방법은 권한을 참고하세요.
CLI 또는 로컬 Codex 설정에서는 approvals_reviewer = "auto_review"를 설정하고 approval_policy = "on-request"와 같이 자동 검토를 지원하는 대화형 승인 정책을 사용하세요. 승인 정책만 변경하면 검토 에이전트가 선택되지 않습니다. 관리자는 조직에서 자동 검토를 필수로 설정할 수 있습니다.
자동 검토의 작동 방식
- 기본 에이전트가 명령어 실행과 같은 작업을 제안합니다.
- 작업에 승인이 필요하면 Codex가 승인 요청을 생성합니다.
approvals_reviewer = "auto_review"이면 Codex는 사람의 승인을 기다리는 대신 별도의 검토 에이전트에 승인 요청을 전달합니다.- 검토 에이전트가 작업의 실행 여부를 결정하고 판단 근거를 반환합니다.
- 승인되면 실행이 계속됩니다. 거부되면 기본 에이전트는 실질적으로 더 안전한 방법을 찾거나 작업을 중단하고 사용자에게 물어보라는 지시를 받습니다.
자동 검토가 실행되는 경우
자동 검토는 원래라면 작업을 일시 중지하고 사람의 응답을 기다려야 하는 승인 요청을 평가합니다. 다음과 같은 경우가 해당됩니다.
- 샌드박스 권한 상승을 요청하는 셸 또는 exec 도구 호출
- 명령어 규칙 중
decision = "prompt"로 설정된 규칙과 일치하는 명령어. 샌드박스 안에서 실행하는 명령어도 포함됩니다. - 승인이 필요한 대상으로 보내는 네트워크 요청. 명시적인 네트워크 거부 규칙이 적용되면 요청이 차단됩니다.
- 쓰기가 허용된 루트 디렉터리 밖의 파일 편집
- 도구 어노테이션이나 설정된 승인 모드에 따라 승인이 필요한 MCP 또는 앱 도구 호출
이미 실행 권한이 있는 작업은 검토 없이 진행됩니다.
컴퓨터 사용 기능의 앱 수준 접근 권한 요청은 사용자에게 직접 표시됩니다. 이와 별개로, 컴퓨터 사용 도구를 호출할 때 해당 호출이 검토 대상이면 자동 검토가 실행될 수 있습니다.
자동 검토가 차단하는 작업
자동 검토는 다음과 같은 작업을 차단하도록 설계되었습니다.
- 비공개 데이터, 시크릿 또는 자격 증명을 신뢰할 수 없는 대상으로 전송하는 작업
- 자격 증명, 토큰, 쿠키 또는 세션 관련 정보를 탐색하는 작업
- 보안을 광범위하게 또는 지속적으로 약화시키는 작업
- 돌이킬 수 없는 피해를 초래할 위험이 큰 파괴적 작업
기본 규칙과 규칙을 맞춤 설정하는 방법은 설정을 참고하세요.
검토 에이전트가 확인하는 정보
검토 에이전트는 승인 요청이 발생한 작업을 개별적으로 평가합니다.
검토 에이전트는 간략한 대화 기록과 승인 요청의 정확한 내용을 확인합니다. 여기에는 일반적으로 사용자 메시지, 사용자에게 표시된 어시스턴트의 진행 상황, 관련 도구 호출과 출력, 현재 승인을 요청한 작업이 포함됩니다. 디렉터리 삭제를 승인하기 전에 해당 디렉터리를 살펴보는 등 읽기 전용으로 확인 작업을 수행할 수도 있습니다.
어시스턴트의 내부 추론은 포함되지 않습니다. 자동 검토에서는 보관된 채팅 항목과 도구에서 얻은 근거를 확인할 수 있지만 비공개 추론 과정은 볼 수 없습니다.
거부 및 실패 시 동작
Codex는 명시적 거부를 일반적인 샌드박스 오류와 다르게 처리합니다. 검토 에이전트의 판단 근거를 기본 에이전트에 전달하고 다음과 같이 더 엄격한 지시를 내립니다.
- 우회 방법, 간접 실행 또는 정책 회피를 통해 같은 결과를 얻으려 하지 마세요.
- 실질적으로 더 안전한 대안이 있을 때만 계속하세요.
- 그렇지 않으면 작업을 중단하고 사용자에게 물어보세요.
대부분의 모델에서 Codex CLI는 같은 턴에서 요청이 3회 연속 거부되거나 최근 50회의 검토 중 거부가 10회에 이르면 해당 턴을 중단합니다. 사이버 보안용으로 지정된 모델에서는 첫 번째 거부가 발생하는 즉시 CLI가 턴을 중단합니다.
검토 결과가 거부가 아니면 연속 거부 횟수가 초기화됩니다. 거부 횟수가 한도에 도달하면 Codex는 경고를 표시하고 해당 턴을 중단합니다.
시간 초과는 명시적 거부와 구분해 표시됩니다. Codex는 기본 에이전트에 시간 초과만으로는 작업이 안전하지 않다고 판단할 수 없다는 점을 알립니다.
Codex에서는 사용자가 거부된 작업의 재시도를 명시적으로 승인할 수도 있습니다. 현재 오픈 소스 TUI에서 /approve를 실행해 자동 검토에서 거부된 작업 목록을 열고, 최근 거부된 작업 중 하나를 선택해 한 번의 재시도를 승인하세요. Codex는 작업별로 최근 거부 내역을 최대 10건 기록합니다. 승인은 거부된 바로 그 작업에만 적용되며 이후의 유사한 작업에는 적용되지 않습니다. 동일한 컨텍스트에서 한 번 재시도할 수 있도록 승인이 기록되며 재시도도 자동 검토를 거칩니다. 내부적으로 Codex는 해당 작업에 대한 승인 표시를 개발자 지시 수준에서 추가합니다. 검토 에이전트는 사용자가 명시적으로 재시도를 승인했다는 사실을 컨텍스트로 참고하면서도 정책을 따릅니다. 정책상 사용자가 해당 유형의 거부 결정을 변경할 수 없다면 검토 에이전트는 재시도도 거부할 수 있습니다.
설정
검토 에이전트 템플릿은 검토 에이전트에 작업을 평가하는 방법을 알려 줍니다. Codex는 이 템플릿에 보안 정책을 삽입하고 응답 형식은 별도로 지정합니다. CLI는 검토 모델의 기본 정책을 사용할 수 있으면 해당 정책을 사용합니다. 그렇지 않으면 CLI에 포함된 정책(policy.md)을 사용합니다.
정책을 교체하려면 수정할 정책의 전체 내용을 복사하세요. CLI에 포함된 기본 정책을 사용한다면 policy.md의 전체 내용을 복사하세요. 변경할 규칙을 수정한 다음 정책 전문을 로컬 설정의 [auto_review].policy 또는 관리형 설정의 guardian_policy_config에 입력하세요. 생략한 규칙은 교체된 정책에 포함되지 않습니다. Codex는 검토 에이전트의 템플릿과 응답 형식을 계속 사용합니다.
관리형 guardian_policy_config는 로컬 [auto_review].policy보다 우선합니다. Codex는 비어 있는 정책 값을 무시합니다.
조직 전체에 적용하는 방법은 자동 검토 정책 설정을 참고하세요.
승인된 사이버 보안 작업 설정
승인된 보안 작업을 수행할 때는 작업 범위를 문서화하고 최소 권한 원칙에 맞는 권한 프로필을 자동 검토와 함께 사용하세요. 승인된 실험 환경의 대상을 사용하고 작업 내용과 수행 기간을 기록하세요. 명시적으로 승인받지 않은 프로덕션 시스템, 무관한 호스트, 자격 증명 및 지속적으로 영향을 미치는 변경은 작업 범위에서 제외하세요.
다음 로컬 config.toml 예시는 자동 검토를 활성화하고 워크스페이스 권한 프로필을 선택합니다.
approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"독립적인 파일 시스템 및 네트워크 규칙으로 작업 대상을 제한하세요. 다음 관리형 requirements.toml 예시는 자동 검토를 필수로 설정하고 사용 가능한 권한 프로필을 제한합니다.
allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.allowed_permission_profiles는 현재 방식의 권한 프로필을 제어합니다. allowed_sandbox_modes는 기존 sandbox_mode를 계속 사용하는 배포 환경에서도 전체 권한을 차단합니다.
approval_policy = "on-request" 또는 자동 검토를 지원하는 다른 대화형 승인 정책을 사용하고, 실제로 강제할 수 있는 샌드박스 경계를 유지하세요. approval_policy = "never", :danger-full-access 또는 --yolo를 사용하면 작업이 샌드박스 경계를 넘어도 검토에 필요한 승인 요청이 생성되지 않을 수 있습니다.
네트워크 대상이 허용 목록에 있다는 이유만으로 검토가 실행되지는 않습니다. 샌드박스 안의 작업도 검토 에이전트에 전달해야 한다면 명시적인 명령어 규칙을 추가해 decision = "prompt"로 설정하거나, 민감한 MCP 도구를 사용할 때 승인이 필요하도록 설정하세요.
모델 액세스, 보안 작업 설정, 사용자 지정 에이전트 워크플로우에 대해서는 모델 및 신뢰할 수 있는 액세스와 권장 설정을 참고하세요. 사용자 지정 API 또는 Agents SDK 하네스를 사용하는 경우 가드레일 및 사람의 검토를 참고하세요.
보안을 유지하면서 검토 요청 줄이기
자동 검토는 자주 사용하는 안전한 워크플로우를 샌드박스 안에서 처리할 수 있을 때 가장 효과적입니다. 일상적인 작업에 검토 요청이 너무 많다면 검토 에이전트가 불필요한 권한 상승 요청을 매번 승인하도록 정책을 조정하기보다 먼저 샌드박스 경계를 조정하세요.
실제로 가장 효과적인 변경은 다음과 같습니다.
- 임시 작업 디렉터리나 의도적으로 함께 사용하는 인접 레포지토리만 포함하도록
writable_roots를 추가하세요. - 적용 범위가 좁은 접두사 규칙을 추가하세요.
["cargo", "test"]또는["pnpm", "run", "lint"]처럼 구체적인 명령어 접두사를 사용하세요.["python"]이나["curl"]처럼 범위가 넓은 패턴을 사용하면 자동 검토가 지켜야 할 경계가 사실상 사라지는 경우가 많습니다. 사이버 보안용 모델에서 CLI는allow접두사 규칙을 무시하고prompt규칙과forbidden규칙을 적용합니다.
자동 검토 세션 기록은 기본적으로 ~/.codex/sessions에 보관됩니다. 정책이나 권한을 변경하기 전에 Codex에 이 기록을 바탕으로 과거 요청을 분석해 달라고 할 수 있습니다.
한계
자동 검토를 사용하면 기본 설정에서도 에이전트가 장시간 작업을 이어가기 쉬워지지만, 모든 작업의 안전을 보장할 수는 없습니다.
- 명시적인 명령어 규칙이나 도구 승인 설정에 따라 발생한 요청을 포함해 검토 대상인 승인 요청만 평가합니다.
- 특히 적대적이거나 이례적인 상황에서는 잘못 판단할 수 있습니다.
- 샌드박스 설계, 모니터링 및 조직별 정책을 보완하는 용도로 사용해야 합니다.
연구 배경과 공개된 평가 결과는 자동 검토에 관한 Alignment Research 게시물을 참고하세요.