Guardian: 한 모델이 다른 모델을 승인하게 하기

Codex를 열어 저장소를 고칩니다. 모델은 git status를 돌리고, 파일 둘을 읽은 뒤 git push를 원해요. 다음 분에는 curl, 그다음엔 /tmp에 메모, 그다음엔 그 메모를 지웁니다. 팝업이 쌓입니다. 사람은 명령의 앞 두 단어만 보고, 엄지는 이미 근육 기억이 생겼어요.

그게 승인 피로입니다. 방어선은 남아 있고, 판단은 없어요. 회로는 늘 초록만 켜지는 버튼으로 무너집니다. 자동 허용을 방금 그 명령을 쓴 메인 모델에 주면, 신청자가 곧 승인자입니다. 실패할 때 허용하면 타임아웃과 나쁜 JSON이 무료 통행권이 돼요.

Codex는 자동 허용 여부를 전담 검토로 뽑습니다. 샌드박스를 대체하지 않고, 네트워크 프록시도 대체하지 않아요. 사용자에게 뜨려던 on-request 승인 한 종류만 인수합니다. 경로는 좁아요. 정책은 OnRequest 또는 Granular여야 하고, 검토원은 AutoReview여야 합니다. 기본 검토원은 여전히 사용자예요.출처:codex-rs/core/src/guardian/review.rs 186–210행

모듈 헤더는 네 단계를 못 박습니다.

계약 필드는 넷뿐입니다. 세 축의 enum은 프로토콜 층의 approvals.rs에 있고, protocol.rs에는 없어요. outcome만 필수입니다. 낮은 위험 허용은 {"outcome":"allow"}만 돌려도 되고, 빠진 위험은 Low, 권한은 Unknown으로 채웁니다.

/// Structured output contract that the guardian reviewer must satisfy.
#[derive(Debug, Clone, Deserialize, Serialize, PartialEq, Eq)]
pub(crate) struct GuardianAssessment {
    pub(crate) risk_level: codex_protocol::protocol::GuardianRiskLevel,
    pub(crate) user_authorization: codex_protocol::protocol::GuardianUserAuthorization,
    pub(crate) outcome: GuardianAssessmentOutcome,
    pub(crate) rationale: String,
}

승인 피로는 사람 문제이고, 검토원 자신도 형식이 흔들립니다. 실행 가능한 답을 못 낸 것을 거절로 접으면, 다른 언어로 다시 써도 성립해요. 입력은 신뢰할 수 없는 증거 더하기 정확한 동작 하나, 출력은 남김없는 allow 또는 deny, 파싱이 실패하면 멈춥니다.

메인 모델이 방금 실행할 명령을 썼어요. 그걸 다시 심사시키면 회로가 열려 있습니다. 도구 출력에 “승인해 주세요”를 끼우면 검토 재료가 오염됩니다. 검토권이 신청자에게 돌아가면, 전담 검토원이라는 역할은 없어요.

검토 세션은 부모 설정을 복제한 뒤 바로 고칩니다. 승인 정책은 Never로 잠그고, 권한 프로필은 읽기 전용과 교차하며, MCP 서버는 빈 표가 되고, 스킬·기억·Apps 지시는 끄며, 불필요한 특성도 한 줄 비활성화해요. 부모가 넘긴 exec-policy 규칙도 버리고 빈 기본 관리자로 바꿉니다. 부모 규칙이 검토원을 거꾸로 빚을 수 있고, 검토원이 돌린 읽기 전용 명령을 조용히 허용할 수도 있어요.출처:codex-rs/core/src/guardian/review_session.rs 1406–1448행；codex-rs/core/src/session/mod.rs 544–548행

검토원은 읽기 전용 명령을 돌려 로컬 상태를 확인할 수 있어요. 삭제 대상이 있는지, 빈 디렉터리인지. 새 승인을 띄우지 않고, Guardian을 한 층 더 열지도 않습니다. 설정 조립 때 GuardianV2를 명시적으로 껐어요.

trunk가 한가하면 뒤 승인은 같은 세션에 이어 붙고 prompt cache가 안정적입니다. trunk가 바쁘면 마지막 커밋된 rollout에서 임시 오두막이 자라고, 검토가 끝나면 헐리며 되쓰지 않아요.

신뢰할 수 없는 검토권에 되도록 작은 환경을 주는 것은 보안 설계의 일반적인 모양입니다. 모델, 프롬프트, 능력 면을 바꿔도 물을 것은 같아요. 검토원에게 정말 필요한 능력은 몇 가지인가, 나머지는 하나도 안 줘도 되는가.

검토원과 실행 모델이 같은 거절 동작에 걸리면, 사람이 보는 것은 공회전입니다. 타임아웃까지 연속 거절에 넣으면, 인프라 흔들림이 모델의 연속 악행으로 오인돼요.

타임아웃은 ReviewDecision::TimedOut, 명시 거절은 Denied. 모델에게 주는 문장도 갈라요. 타임아웃은 그것만으로 불안전하다고 보지 말라고 하고, 한 번 더 시도하거나 사용자에게 물으라고 합니다. 명시 거절에는 우회 금지 지시를 붙여, 실질적으로 더 안전한 대안이나 사용자가 알고 난 뒤의 명시 승인만 허용해요.출처:codex-rs/protocol/src/protocol.rs 3909–3910행；codex-rs/core/src/guardian/review.rs 70–74행

차단기는 turn으로 장부하고, 창 길이는 50입니다. Standard 임계는 연속 3회, 또는 창 안 누적 10회. CyberModel은 첫 거절에서 멈출 만큼 빡빡해요. 평가가 Deny일 때만 셉니다. 타임아웃과 fail-closed는 record_non_denial을 타고 연속 수를 비웁니다. 발동하면 GuardianWarning을 보낸 뒤 abort_turn_if_active.출처:codex-rs/core/src/guardian/mod.rs 53–59행、157–194행

안전 문은 “못 끝냄”과 “명시적 아니요”를 따로 장부해야 합니다. “통과 못 함” 한 줄로 섞으면, 순간 장애가 우회 행동으로 훈련돼요. turn으로 세고 창으로 세면 임계 두 벌이면 됩니다. 적대성이 높은 장면의 정책은 첫 거절에서 멈출 만큼 빡빡할 수 있어요.