자동 검토
자동 검토
Codex가 샌드박스 경계 승인을 검토자 에이전트로 라우팅하는 방식
자동 검토는 샌드박스 경계에서 사람이 직접 승인하는 절차를 별도의 검토자 에이전트로 대체합니다. 기본 Codex 에이전트는 여전히 동일한 샌드박스 안에서 동일한 승인 정책과 동일한 네트워크 및 파일 시스템 제한을 적용받으며 실행됩니다. 달라지는 점은 적격한 권한 상승 요청을 누가 검토하느냐입니다.
ChatGPT 데스크톱 앱에서 승인된 Daybreak 모델을 선택하면 계정에서
Approve for me 모드를 사용할 수 있고 조직 정책에서 허용하는 경우 권한 제어가
해당 모드로 자동 전환됩니다. 데스크톱 앱의 /model 명령을 사용할 때도
마찬가지입니다. 해당 모드를 사용할 수 없으면 현재 권한 모드가 변경되지 않습니다. 모델 선택은
관리형 조직 요구 사항을 재정의하지 않습니다.
승인된 보안 모델에 Full Access를 사용 설정하기 전에 ChatGPT 데스크톱 앱은 위험한 작업에 대한 모델별 경고를 표시합니다. 이 경고는 대신 Approve for me를 사용하도록 권장하고 검토자 정책 구성으로 연결합니다. 이 경고는 샌드박스 경계를 복원하거나 조직 정책을 재정의하지 않습니다.
자동 검토 작동 방식
전체적인 흐름은 다음과 같습니다.
- 기본 에이전트는
read-only또는workspace-write안에서 작업합니다. - 샌드박스 경계를 넘어야 할 때 승인을 요청합니다.
approvals_reviewer = "auto_review"인 경우 Codex는 사람의 응답을 기다리는 대신 해당 승인 요청을 별도의 검토자 에이전트로 라우팅합니다.- 검토자는 작업을 실행해도 되는지 결정하고 그 근거를 반환합니다.
- 작업이 승인되면 실행이 계속됩니다. 거부되면 기본 에이전트는 실질적으로 더 안전한 경로를 찾거나 중단하고 사용자에게 문의하라는 지시를 받습니다.
자동 검토는 검토자를 교체하는 기능이지 권한을 부여하는 기능이 아닙니다. 이 기능은
writable_roots를 확장하거나 네트워크 액세스를 활성화하거나 보호된 경로의 제한을 완화하지 않습니다. 이미
승인이 필요한 작업을 Codex가 처리하는 방식만 변경합니다.
작동 조건
자동 검토는 그렇지 않으면 사람의 응답을 기다리며 일시 중지될 승인 요청을 평가합니다. 여기에는 다음이 포함됩니다.
- 상향된 샌드박스 권한을 요청하는 셸 또는 exec 도구 호출.
- 현재 샌드박스 또는 정책에 의해 차단된 네트워크 요청.
- 허용된 쓰기 가능 루트 외부의 파일 편집.
- 도구 주석이나 구성된 승인 모드에 따라 승인이 필요한 MCP 또는 앱 도구 호출.
- 새로운 웹사이트 또는 도메인에 대한 Computer Use 액세스.
자동 검토는 샌드박스 안에서 이미 허용된 일반적인 작업에는 실행되지
않습니다. 명령을 활성 sandbox_mode에서 실행할 수 있거나 도구 호출이
허용된 정책 범위 안에 있으면 기본 에이전트는 검토 없이 계속 진행합니다.
Computer Use는 별도의 사례입니다. Computer Use의 앱 승인은 여전히 사용자에게 직접 표시되므로 자동 검토가 이러한 앱 수준 프롬프트를 대체하지 않습니다.
자동 검토가 차단하는 작업
개괄적으로 자동 검토는 다음과 같은 작업을 차단하도록 설계되었습니다.
- 비공개 데이터, 비밀 정보 또는 자격 증명을 신뢰할 수 없는 대상으로 전송하는 작업
- 자격 증명, 토큰, 쿠키 또는 세션 자료를 탐색하는 작업
- 광범위하거나 지속적으로 보안을 약화하는 작업
- 되돌릴 수 없는 손상을 일으킬 위험이 큰 파괴적 작업
정확한 정책은 오픈 소스 Codex 저장소의 다음 파일에 있습니다.
policy_template.md
및
policy.md.
이 정책은 기업별로 guardian_policy_config을 사용해 맞춤 설정하거나
사용자별로 로컬 [auto_review].policy을 사용해 맞춤 설정할 수 있습니다.
검토자가 확인하는 정보
검토자 역시 Codex 에이전트이지만 기본 에이전트보다 역할이 제한적입니다. 즉, 특정 경계 통과 작업을 실행해도 되는지 결정합니다.
검토자는 간결한 대화 기록과 정확한 승인 요청을 확인합니다. 여기에는 일반적으로 사용자 메시지, 사용자에게 표시된 어시스턴트 업데이트, 관련 도구 호출과 도구 출력, 그리고 현재 승인이 제안된 작업이 포함됩니다. 누락된 컨텍스트를 수집하기 위해 읽기 전용 검사를 수행할 수도 있지만, 이는 드문 경우입니다.
숨겨진 어시스턴트 추론은 포함되지 않습니다. 자동 검토는 보존된 채팅 항목과 도구 증거를 확인하며 비공개 사고 과정은 확인하지 않습니다.
거부 및 실패 시 동작
명시적인 거부는 일반적인 샌드박스 오류처럼 처리되지 않습니다. Codex는 검토 근거를 기본 에이전트에 반환하고 더 강력한 지시를 추가합니다.
- 우회 방법, 간접 실행 또는 정책 회피를 통해 동일한 결과를 추구하지 마세요.
- 실질적으로 더 안전한 대안이 있을 때만 계속 진행하세요.
- 그렇지 않으면 중단하고 사용자에게 문의하세요.
Codex는 턴별로 거부 회로 차단기도 적용합니다. 현재
오픈 소스 구현에서 자동 검토는 연속으로 3번 거부되거나 동일한 턴에서 최근 50번의
검토로 구성된 이동 창 내에서 10번 거부되면 턴을 중단합니다.
거부가 아닌 결과가 나오면 연속 거부 카운터가 초기화됩니다. 차단기가 작동하면 Codex는 에이전트가 추가 권한 상승 시도를 반복하도록 두는 대신 경고를 표시하고 인터럽트로 현재 턴을 중단합니다.
시간 초과는 명시적인 거부와 별도로 표시되며 기본 에이전트에는 시간 초과만으로 해당 작업이 안전하지 않다는 사실이 입증되는 것은 아니라고 안내됩니다.
거부된 작업을 위한 명시적인 재정의 경로도 있습니다. 현재
오픈 소스 TUI에서 /approve을 실행해 자동 검토 거부 선택기를 연 다음
최근 거부된 작업 하나를 선택하여 한 번의 재시도를 승인합니다. Codex는 작업별로 최근
거부 기록을 최대 10개까지 보관합니다. 이 승인은 제한적입니다. 정확히
거부된 작업에만 적용되고 향후 유사한 작업에는 적용되지 않으며, 동일한
컨텍스트에서 한 번의 재시도에만 적용되도록 기록되고, 재시도 역시 자동 검토를 거칩니다. 내부적으로
Codex는 해당 작업에 정확히 대응하는 개발자 범위의 승인 마커를 삽입합니다.
검토자는 이러한 명시적 사용자 재정의를 컨텍스트로 확인하지만, 여전히
정책을 따르며 사용자가 해당 종류의 거부를 재정의할 수 없다고 정책에 명시된 경우 다시
거부할 수 있습니다.
구성
설정에 관한 자세한 내용은 관리형 구성을 참조하세요.
기본 검토자 정책은 오픈 소스 Codex 저장소의 다음 파일에 있습니다.
core/src/guardian/policy.md.
기업은 관리형 요구 사항에서 guardian_policy_config을 사용하여 테넌트별 섹션을
대체할 수 있습니다. 개별 사용자도 자신의 config.toml에서 로컬
[auto_review].policy을
설정할 수 있지만 관리형 요구 사항이 우선합니다.
[auto_review]
policy = """
YOUR POLICY GOES HERE
"""정책을 맞춤 설정하려면 먼저 기본 정책의 전체 문구를 복사한 다음 개별 위험 프로필에 따라 조정하세요.
승인된 사이버 보안 작업 구성
승인된 보안 작업에서는 자동 검토를 서면으로 작성된 작업 범위 및 최소 권한 권한 프로필과 함께 사용하세요. 승인된 실습 대상만 사용하고, 수행할 작업과 작업 기간을 문서화하며, 명시적으로 승인되지 않은 프로덕션 시스템, 관련 없는 호스트, 자격 증명, 영구적 변경 사항은 범위에서 제외하세요.
[auto_review].policy과 guardian_policy_config은 모두 현재
검토자 정책을 대체합니다. 모델에 번들로 포함되거나 조직에서 관리하는 정책과
병합되지 않습니다. 기본 제공 검토 지침과 응답
형식은 계속 적용됩니다. 두 예시 중 하나를 사용하기 전에 현재 정책 전체를 복사하고,
기존 규칙을 모두 유지한 다음, 승인된 작업에 관한 규칙을 추가하세요.
대문자로 된 자리 표시자를 해당 전체 정책으로 바꾸세요. 현재 정책에
액세스할 수 없다면 재정의하지 마세요.
다음 로컬 config.toml 템플릿은 검토를 사용 설정하고 기존
검토자 정책 뒤에 범위가 지정된 조건을 추가합니다.
approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"
[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.
## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
and validate fixes within the documented engagement window.
## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
approves the exact target, action, and side effects.
"""예시 대상과 허용된 작업을 실제 승인 범위로 바꾸세요. 독립적인 파일 시스템 및 네트워크 규칙으로 대상 제한을 적용하세요. 검토자 지침은 이러한 경계를 대체하지 않습니다.
조직에서는 관리형 requirements.toml에 동일한 조건을 적용할 수 있습니다.
allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"
guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.
## Environment Profile
- Authorized target: lab.example.com.
## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
exact target, action, and side effects.
"""
[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을 사용하는 배포 환경에서도 전체 액세스를 차단합니다.
관리형 guardian_policy_config은 사용자의 로컬
[auto_review].policy보다 우선합니다. approval_policy = "on-request" 또는 그 밖의
적격 대화형 승인 정책과 시행 가능한 샌드박스 경계를 유지하세요.
approval_policy = "never", :danger-full-access 또는 --yolo을 사용하면 작업이
검토에 필요한 경계 통과 승인 요청을 생성하지 않을 수 있습니다.
허용 목록에 있는 네트워크 대상이라는 이유만으로 검토가 트리거되지는 않습니다. 샌드박스
내부의 작업도 검토자에게 전달해야 하는 경우에는 decision = "prompt"이 포함된 명시적
명령 규칙을 추가하거나 민감한 MCP 도구가 승인을 요구하도록
구성하세요.
모델 액세스, 작업 설정 및 사용자 지정 에이전트 워크플로에 대해서는 모델 및 Trusted Access와 권장 구성을 참조하세요. 엔터프라이즈 우선순위와 지원되는 클라이언트 버전에 대해서는 관리형 구성을 참조하세요. 사용자 지정 API 또는 Agents SDK 하네스에는 가드레일 및 사람의 검토를 사용하세요.
보안을 약화하지 않고 검토량 줄이기
자동 검토는 샌드박스가 일반적으로 사용하는 안전한 워크플로를 이미 포괄할 때 가장 효과적으로 작동합니다. 사소한 작업에 너무 많은 검토가 필요하다면 검토자가 시끄러운 권한 상승을 계속 승인하도록 가르치기 전에 먼저 경계를 수정하세요.
실제로 가장 큰 효과를 내는 변경 사항은 다음과 같습니다.
- 의도적으로 사용하는 임시 디렉터리나 인접 저장소를 위해 범위가 좁은
writable_roots을 추가합니다. - 범위가 좁은 접두사 규칙을 추가합니다.
["python"]또는["curl"]같은 광범위한 패턴보다["cargo", "test"]또는["pnpm", "run", "lint"]같은 정확한 명령 접두사를 사용하는 것이 좋습니다. 광범위한 규칙은 자동 검토가 보호하도록 설계된 바로 그 경계를 없애는 경우가 많습니다.
자동 검토 세션 대화 기록은 기본적으로 ~/.codex/sessions 아래에
보관되므로 정책이나 권한을 변경하기 전에 Codex에 과거 트래픽을 분석하도록
요청할 수 있습니다.
제한 사항
자동 검토는 장시간 실행되는 에이전트 작업의 기본 작동 지점을 개선하지만 결정론적 보안을 보장하지는 않습니다.
- 경계를 넘도록 요청하는 작업만 평가합니다.
- 특히 적대적이거나 일반적이지 않은 컨텍스트에서는 여전히 실수할 수 있습니다.
- 우수한 샌드박스 설계, 모니터링 및 조직별 정책을 대체하는 것이 아니라 보완해야 합니다.
연구 배경과 공개된 평가 결과는 자동 검토에 관한 Alignment Research 게시물을 참조하세요.