Codex 보안 쿡북

직원이 회사 ChatGPT 워크스페이스를 통해 Codex에 로그인해야 하고 관리 대상 엔드포인트에서 개인 ChatGPT 계정과 API 키 인증을 금지해야 할 때 이 레시피를 사용하세요.

목표

회사 관리 기기에서 Codex는 회사 ChatGPT 워크스페이스에 대한 ChatGPT 로그인만 허용합니다.

사전 준비

• 승인된 ChatGPT Enterprise 워크스페이스의 UUID를 확인하세요.

• 엔드포인트에 Codex 관리형 설정을 배포할 수단을 마련하세요.

• 관리 대상 엔드포인트에서 API 키 인증을 금지하기로 결정하세요.

설정

1. 승인된 워크스페이스 UUID를 내부 설정 리포지터리에 기록하세요.

2. 로컬 requirements.toml에 강제할 인증 요구 사항을 추가하세요.

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

   첫 번째 키는 ChatGPT 인증만 허용하고, 두 번째 키는 승인된 워크스페이스로 로그인을 제한합니다. 예시 UUID를 실제 워크스페이스 UUID로 바꾸세요. 요구 사항 레퍼런스를 참고하세요.

3. 로컬 requirements.toml 또는 macOS MDM 요구 사항을 통해 배포하세요. 배포 경로는 설정을 배치할 위치에서 확인하세요. 이 인증 요구 사항은 자격 증명을 불러오거나 클라우드 정책을 가져오기 전에 적용됩니다. Codex는 클라우드 관리형 요구 사항에 포함된 인증 요구 사항을 무시합니다. 사용자가 파일과 상위 디렉터리를 수정하지 못하도록 보호하세요. 레거시 managed_config.toml의 기본값으로는 이 제한을 강제할 수 없습니다.

4. 시범 적용 기간에 사용자를 로그아웃시키거나 기존에 저장된 개인 Codex 세션을 제거하세요. 새 정책이 기존 세션까지 소급해 무효화한다고 가정하지 마세요.

5. 로그인 제한을 워크스페이스 역할 및 그룹 접근 권한과 함께 적용하세요. 인증은 어떤 ID로 로그인할 수 있는지를 결정하고, 역할 기반 접근 제어(RBAC)는 해당 ID로 어떤 Codex 기능을 사용할 수 있는지를 결정합니다. 인증을 참고하세요.

검증

• Codex에서 로그아웃하세요.

• 개인 ChatGPT 계정으로 로그인을 시도하세요. 개인 워크스페이스 로그인이 거부되어야 합니다.

• Codex에 API 키로 로그인을 시도하세요. API 키 로그인이 거부되어야 합니다.

• 회사 계정으로 승인된 워크스페이스에 로그인하세요. 로그인이 성공해야 합니다.

• 데스크톱 앱, CLI, IDE 확장 프로그램을 다시 시작한 다음 검증을 반복하세요.

롤백

이전 로컬 인증 요구 사항을 복원하고 검토를 마친 번들을 다시 배포하세요.

적용 한계

이 설정은 관리 대상 엔드포인트의 관리형 Codex 클라이언트에 적용됩니다. 요구 사항이 ‘회사 자산에서 Codex 개인 사용 금지’라면 엔드포인트의 애플리케이션 통제 수단과 네트워크 정책을 함께 적용하세요.

개발자에게 읽기 전용 또는 워크스페이스 범위의 접근 권한이 필요하지만, 전체 권한을 선택하거나 --yolo로 승인과 샌드박스를 우회하지 못하게 하려면 이 레시피를 사용하세요.

목표

사용자는 승인된 읽기 전용 또는 워크스페이스 범위의 프로필만 선택할 수 있습니다. danger-full-access, approval_policy = "never", --yolo는 선택할 수 없습니다.

설정

1. 승인된 워크스페이스 프로필을 정의하세요.

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. 허용할 프로필과 승인 정책을 강제하세요.

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

   허용 목록에는 허용할 프로필을 모두 명시해야 합니다. 목록에서 빠지거나 false로 설정된 프로필은 거부되며, 향후 버전에서 추가되는 프로필도 마찬가지입니다. 설정 레퍼런스를 참고하세요.

3. 여전히 sandbox_mode를 사용하는 레거시 클라이언트에는 다음 설정을 사용하세요.

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. 사용자가 편집할 수 있는 설정 파일 대신 관리자가 강제하는 요구 사항으로 배포하세요.

5. 나중에 자동 검토를 허용하려면 테스트를 거친 후 명시적으로 추가하세요. 자동 검토는 허용 범위를 벗어나는 작업의 검토 주체를 바꿉니다. 이미 제거한 제한을 복원하지는 않습니다. 자동 검토를 참고하세요.

검증

• 권한 선택 메뉴를 여세요. 전체 권한을 선택할 수 없거나 선택이 거부되어야 합니다.

• --dangerously-bypass-approvals-and-sandbox로 실행하세요. Codex가 실행을 거부하거나 호환되는 프로필을 강제해야 합니다.

• --sandbox danger-full-access --ask-for-approval never로 실행하세요. 실행이 거부되어야 합니다.

• 일반적인 워크스페이스 작업을 실행하세요. 작업은 성공하고, 허용 범위를 벗어나는 작업에는 여전히 승인이 필요해야 합니다.

롤백

이전 요구 사항 번들을 복원하세요. 별도로 승인된 예외가 없으면 무제한 접근은 계속 차단하세요.

적용 한계

이 설정은 Codex 런타임 권한을 제어합니다. 운영체제 계정에 부여된 특권까지 제거하지는 않습니다.

조직에서 Codex가 사용할 수 있는 MCP 서버를 정하고 승인된 목록을 강제해야 할 때 이 레시피를 사용하세요.

서버 허용과 서버 설정은 별도 단계입니다. 허용 목록 항목은 일치하는 서버의 사용을 허용하지만 서버 설정을 생성하지는 않습니다. 이름과 식별 정보가 일치하도록 서버를 별도로 설정하고 서버에 필요한 인증도 구성하세요.

목표

Codex는 설정된 이름과 식별 정보가 기업의 승인 목록과 일치하는 MCP 서버만 활성화합니다.

설정

1. 승인된 각 서버의 소유자, 용도, 전송 방식, 정확한 실행 파일 또는 URL, 인증 방식, 데이터 분류, 쓰기 작업이 가능한 도구를 목록으로 정리하세요.

2. 우선 모두 차단하세요. 관리형 테이블을 비워 두면 모든 MCP 서버가 비활성화됩니다.

   [mcp_servers]

3. 승인된 HTTP 서버를 정확한 URL로 추가하세요.

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. 승인된 stdio 서버를 실행 파일과 위치 인수로 추가하세요.

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

   이 구조화된 일치 규칙은 실행 파일, 인수 개수, 인수 순서를 검사합니다. cwd, env, env_vars는 제한하지 않습니다. stdio 서버를 승인하기 전에 전체 실행 컨텍스트를 통제할 수 있어야 합니다. 실행 파일과 종속성을 보호하고, 신뢰할 수 없는 사용자 또는 프로젝트 설정에서 서버 동작을 바꿀 수 있는 작업 디렉터리나 환경을 지정하지 못하게 하세요. 이 제한을 독립적으로 강제할 수 없다면 stdio 서버를 승인하지 말고 검토를 마친 HTTP 서버를 사용하세요.

5. 플러그인에 포함된 MCP 서버의 식별 정보는 plugins.<plugin>.mcp_servers.<server> 아래에 별도로 추가하세요.

6. 승인 목록을 검토 절차가 적용되는 설정 리포지터리에 보관하고 관리자가 강제하는 요구 사항을 통해 배포하세요.

클라이언트는 서버의 이름과 식별 정보가 모두 승인된 항목과 일치할 때만 서버를 활성화합니다. 관리형 설정을 참고하세요.

검증

• 승인된 서버를 승인 항목과 정확히 일치하도록 설정하세요. 서버가 시작되어야 합니다.

• URL에서 한 글자를 바꾸세요. 서버가 비활성화되어야 합니다.

• stdio 인수 개수나 순서를 바꾸거나 설정된 인수 규칙에 맞지 않는 인수를 전달하세요. 서버가 비활성화되어야 합니다. 허용된 접두사와 여전히 일치하는 값은 계속 허용됩니다.

• 테스트 후 폐기할 수 있는 신뢰된 프로젝트에서 일치하는 실행 파일과 인수를 유지한 채 cwd, env, env_vars를 무해한 값으로 재정의해 보세요. 식별 정보 일치 검사만으로는 이러한 재정의를 거부하지 않습니다. 별도의 실행 컨텍스트 통제가 안전하지 않은 재정의를 거부하는지, 또는 stdio 서버가 미승인 상태로 유지되는지 확인하세요. 실제 인젝션 페이로드는 사용하지 마세요.

• 승인되지 않은 이름을 추가하세요. 서버가 비활성화되어야 합니다.

• 플러그인에 포함된 서버를 테스트하세요. 승인된 식별 정보로만 서버가 작동해야 합니다.

롤백

새로 추가한 항목을 제거하세요. 모든 MCP 사용을 즉시 중지하려면 빈 mcp_servers 테이블을 배포하세요.

적용 한계

식별 정보를 허용 목록에 추가했다고 해서 서버의 도구, 업스트림 데이터, 자격 증명, 실행 환경이 안전하다고 볼 수는 없습니다. 로컬 stdio MCP 프로세스는 로컬 명령어 샌드박스 밖에서 실행됩니다. 실행 파일과 인수가 일치하더라도 서버의 접근 범위가 제한되거나 환경을 통한 코드 로딩이 차단되지는 않습니다. 전체 실행 컨텍스트와 서버 권한을 별도로 검토하세요. MCP 식별 정보 요구 사항을 참고하세요.

보안팀이 엔드포인트와 네트워크에서 Codex가 수행하는 작업을 파악해야 할 때 이 레시피를 사용하세요. 실행 및 도구 이벤트, 승인 결정, 워크스페이스 감사 기록, 네트워크 로그를 함께 조사할 수 있습니다.

목표

보안팀은 모델의 설명에 의존하지 않고 Codex 실행, 도구 사용 결정, 승인, 워크스페이스 감사 기록, 실제 아웃바운드 네트워크 트래픽을 서로 연계해 분석할 수 있습니다.

네 가지 증거 출처 활용

1. Codex OpenTelemetry는 실행, API, 모델, 샌드박스, 승인, 도구 이벤트를 기록합니다.

2. 관리형 수명 주기 훅은 엔드포인트에서 도구 사용 및 권한 요청에 관한 기록을 남깁니다.

3. 네트워크 프록시 또는 게이트웨이 로그에는 실제 DNS/HTTP 접속 대상과 연결 결과가 남습니다.

4. Compliance API는 워크스페이스 수준의 감사 및 조사 기록을 제공합니다.

이 중 어느 하나만으로는 네트워크 활동 전체를 모니터링할 수 없습니다.

설정

1. 원본 프롬프트 내용을 제외하고 Codex OpenTelemetry 로그를 수집기로 전송하세요.

   [otel]
   environment = "enterprise"
   log_user_prompt = false
   
   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

   클라이언트를 시작하기 전에 승인된 시크릿 관리자 또는 프로세스 환경을 통해 Codex 프로세스에 OTLP_TOKEN을 제공하세요. 배포하는 TOML 파일이나 소스 제어 시스템에 토큰을 넣지 마세요.

   Codex는 대화 시작, API 요청, 스트리밍 이벤트, 프롬프트 메타데이터, 도구 사용 결정, 도구 결과를 내보낼 수 있습니다. 고급 설정을 참고하세요.

2. 프로젝트 로컬 설정과 별도로 OTel을 배포하세요. 프로젝트의 .codex/config.toml 파일로는 텔레메트리 전송 경로를 재정의할 수 없습니다.

3. SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop, SessionEnd에 관리형 수명 주기 훅을 추가하세요.

4. 훅 스크립트를 관리자가 관리하는 디렉터리에 설치하세요. 사용자, 프로젝트, 플러그인 훅을 무시해야 한다면 allow_managed_hooks_only = true를 설정하세요.

5. 샌드박스에서 실행되는 명령어의 트래픽이 별도로 로그를 남기는 프록시를 거치도록 하세요. OTel은 도구 실행 사실을 기록하고, 프록시는 하위 프로세스가 연결을 시도한 대상을 기록합니다.

6. 웹 검색, 앱, 커넥터, MCP 서버, 브라우저 활동, Codex Cloud의 텔레메트리는 별도로 설정하세요. 로컬 명령어 프록시 규칙은 여기에 자동으로 적용되지 않습니다.

7. 지원되는 Compliance API 기록을 SIEM으로 스트리밍하고 조직의 데이터 보존 정책과 법적 보존 조치를 적용하세요. Compliance API 및 감사 이벤트를 참고하세요.

8. 사용자 또는 서비스 계정, 호스트 또는 러너, 대화 ID, 모델, 클라이언트 버전, 권한 프로필, 승인 결정, 접속 대상, 도구 이름을 서로 연계하세요.

검증

통제된 세션에서 다음 작업을 수행하세요.

• 허용된 파일 하나를 읽으세요.

• 차단된 파일 하나를 읽어 보세요.

• 허용된 명령어 하나를 실행하세요.

• 차단된 아웃바운드 요청 하나를 시도하세요.

• 승인을 요청하고 거부 응답을 받으세요.

• 세션을 종료하세요.

출처별로 다음 결과를 확인하세요.

• OTel에 실행 및 도구 이벤트가 표시됩니다.

• 훅 기록에서 세션의 수명 주기를 확인할 수 있습니다.

• 프록시 로그에 허용된 접속 대상과 차단된 접속 대상이 표시됩니다.

• 규정 준수 데이터 수집 시스템이 지원되는 기록을 수신합니다.

• SIEM이 해당 기록을 사용자 또는 워크로드와 연계합니다.

롤백

이전 설정을 복원해 내보내기 모듈과 훅을 비활성화하세요. 텔레메트리를 롤백할 때 별도로 운영하는 프록시 로깅까지 제거하지 마세요.

적용 한계

Codex 텔레메트리가 모든 명령어 인수, 출력의 모든 바이트, 모든 네트워크 패킷을 포착한다고 보장하지 마세요. 각 계층에서 관측할 수 있는 범위를 문서화하세요.

Codex의 인터넷 접근을 차단하거나 승인된 대상에만 접속하도록 하려면 이 레시피를 사용하세요. 설정하려는 환경에 따라 로컬 또는 클라우드 절차를 선택하세요. 두 환경의 정책 적용 범위는 서로 다릅니다.

목표

선택한 설정에 따라 Codex의 인터넷 접근을 차단하거나 승인된 도메인에만 접속하도록 합니다. Codex Cloud(레거시) 환경에서는 HTTP 메서드도 제한할 수 있습니다.

현재 버전의 Codex Cloud 설정

1. 신뢰 수준에 따라 no-internet-review, approved-dependencies-build, cyber-lab처럼 환경을 분리하세요.

2. 환경 설정에서 모든 공용 인터넷 접근 허용과 패키지 관리자 도메인 허용을 끄세요.

3. 공용 인터넷 접근이 필요하면 추가 허용 도메인에 승인된 호스트를 정확히 입력하세요. 승인되지 않은 공용 대상에 대한 접근을 허용하는 HTTP 시크릿을 제거하세요. VPN 외부의 공용 인터넷 접근을 차단하려면 목록을 비워 두고 공용 대상에 대한 접근을 허용하는 HTTP 시크릿을 제거하세요.

4. 설정을 저장하고 설정 단계에서 서비스를 테스트하세요. 환경을 게시하거나 다시 게시한 다음 새 작업에서 승인된 대상과 승인되지 않은 대상에 대한 접근을 테스트하세요. 설정 스크립트는 별도로 검토하세요. 종속성 버전을 고정하고, 승인된 미러를 우선 사용하고, 검토하지 않은 실행 파일은 다운로드하지 마세요.

서비스에 연결하기를 참고하세요. 현재 Codex Cloud 설정에는 레거시 버전의 HTTP 메서드 선택 기능이 없습니다.

Codex Cloud(레거시) 설정

1. 에이전트의 인터넷 접근이 필요 없으면 꺼짐 상태로 두세요. 레거시 클라우드는 기본적으로 에이전트 단계에서 인터넷을 차단하지만, 설정 스크립트는 종속성 설치를 위해 인터넷에 접근할 수 있는 상태에서 실행됩니다.

2. 에이전트에 인터넷 접근이 필요하면 켜짐으로 전환하고 허용 목록을 좁게 설정하세요. 없음에서 시작해 정확한 도메인을 추가하세요.

3. 다운로드만 필요한 워크플로우에서는 GET, HEAD, OPTIONS만 허용하세요. 그러면 POST, PUT, PATCH, DELETE를 비롯한 다른 메서드가 차단됩니다. 에이전트 단계의 제한은 설정 스크립트의 인터넷 접근에 적용되지 않으므로 스크립트를 별도로 검토하세요.

레거시 에이전트의 인터넷 접근을 참고하세요. 이 사전 설정과 HTTP 메서드 제어는 레거시 클라우드에만 적용됩니다.

로컬 Codex 설정

1. 관리자가 관리하는 requirements.toml에서 승인된 네트워크 프로필을 정의하고 선택한 다음, 사용자가 해당 프로필만 사용하도록 제한하세요.

   default_permissions = "corp-build"
   
   [allowed_permission_profiles]
   "corp-build" = true
   
   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"
   
   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false
   
   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. 관리형 설정에 따라 검토를 마친 요구 사항 번들을 배포하세요. 프로필에 이름을 지정하는 것만으로는 활성화되지 않습니다. default_permissions로 프로필을 선택하고 허용 목록으로 다른 프로필 선택을 막습니다.

3. 같은 요구 사항 번들에서 관리형 프록시를 활성화해 도메인 제한을 강제하고 사용자가 허용 범위를 넓히지 못하게 하세요. 프록시와 네트워크 사용 프로필을 함께 배포하세요. 프록시가 활성화되지 않은 상태에서 네트워크 사용 프로필을 적용하면 도메인 규칙을 강제하지 않고 직접 네트워크 접근을 허용합니다.

   주의: [experimental_network]는 실험적 기능이며 변경될 수 있습니다. 배포 범위를 확대하기 전에 지원하는 각 로컬 클라이언트 버전과 운영체제에서 검증하세요. Windows 지원에는 제한이 있으므로 실제 환경에서 정책이 강제되는지 테스트한 후에만 Windows 사용자에게 적용하세요.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true
   
   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. 워크플로우에 필요하지 않으면 로컬 포트 바인딩을 꺼 두세요. 사설 네트워크 대상에 대한 접근은 별도로 설정하세요. 도메인을 허용해도 해당 도메인의 사설 주소까지 자동으로 승인되지는 않습니다. 네트워크 접근 요구 사항을 참고하세요.

5. 웹 검색, 앱, MCP 서버, 브라우저 활동, Codex Cloud는 별도로 설정하세요. 로컬 샌드박스 규칙은 여기에 적용되지 않습니다.

검증

• 승인된 도메인에 요청을 보내 성공하는지 확인하세요.

• 승인되지 않은 도메인에 요청을 보내 차단되는지 확인하세요.

• 로컬호스트, 사설 IP, 클라우드 메타데이터 엔드포인트에 요청을 보내세요. 명시적으로 승인된 경우를 제외하고 각 요청이 차단되는지 확인하세요.

• Codex Cloud(레거시)에서 허용된 도메인에 POST 요청을 시도하세요. GET, HEAD, OPTIONS만 허용한 경우 요청이 차단되는지 확인하세요.

• 프록시 또는 게이트웨이 로그에 허용된 요청과 거부된 요청이 모두 기록되는지 확인하세요.

롤백

환경의 인터넷 접근을 다시 끄거나 이전 도메인 정책을 복원하세요. 인터넷 접근을 무제한으로 허용하는 상태로 되돌리지 마세요.

적용 한계

샌드박스 제한을 전부 해제하는 권한 상승이 승인되면 로컬 명령어 프록시를 우회할 수 있습니다. 이 제한에 의존하기 전에 일반 샌드박스 명령어와 권한 상승이 승인된 명령어를 별도로 테스트하세요.

허용된 도메인에도 프롬프트 인젝션, 변조된 패키지, 안전하지 않은 문서가 있을 수 있습니다.

Codex가 승인된 소스 디렉터리에 접근해야 하지만 시크릿, .env 파일, SSH 키, 관련 없는 리포지터리에는 접근하지 못하게 하려면 이 레시피를 사용하세요. 파일 접근을 제한하고 하위 프로세스로 실행하는 명령어에 전달되는 환경 변수 중 자격 증명이 포함된 변수를 줄이는 방법을 설명합니다.

목표

Codex는 승인된 소스 디렉터리에서 작업할 수 있지만 시크릿을 담는 일반적인 파일은 읽을 수 없으며, 자격 증명이 포함된 환경 변수를 광범위하게 상속하지 않습니다.

설정

1. 워크스페이스 프로필에 읽기를 거부할 패턴을 정의하세요.

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"
   
   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6
   
   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. 알려진 자격 증명 디렉터리, 서명 키, 프로덕션 설정, 인접 리포지터리의 정확한 경로를 거부 대상으로 추가하세요.

3. 시스템의 /etc/codex/config.toml 또는 사용자의 ~/.codex/config.toml에서 하위 프로세스로 실행하는 명령어에 전달할 환경 변수를 줄이세요.

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false
   
   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

   이 설정은 사용자가 변경할 수 있는 기본값이므로 강제되지 않습니다. 상속되는 변수를 줄이지만 자격 증명 파일, 자격 증명 헬퍼, 셸 초기화 시 불러오는 내용, 다른 ID에 대한 접근까지 막지는 않습니다. 고급 설정을 참고하세요.

4. 관리자가 관리하는 requirements.toml에서 제한된 프로필을 선택하고 해당 프로필만 허용하세요. 기본 제공 프로필은 이 프로필의 시크릿 파일 접근 거부 규칙을 상속하지 않습니다.

   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. 클라우드 환경에 맞는 자격 증명 전달 플로우를 선택하세요.

   • 현재 Codex Cloud에서는 허용된 HTTPS 서비스에 자격 증명을 보낼 때 HTTP 시크릿을 사용하세요. 프로그램은 자리표시자를 받고, 설정 및 작업 실행 중에 포트 443으로 승인된 대상에 접속하면 프록시가 자리표시자를 실제 값으로 바꿉니다. 원본 자격 증명은 로컬 프로세스에 전달되거나 파일에 기록되지 않습니다. 직접 설정한 환경 변수는 프로그램에서 사용할 수 있습니다. 환경 변수 및 네트워크 시크릿을 참고하세요.
   • Codex Cloud(레거시)에서 시크릿은 설정 단계의 인증에 사용되며 에이전트 단계 전에 제거됩니다. 환경 변수는 채팅이 끝날 때까지 유지됩니다. 레거시 클라우드 환경을 참고하세요.

6. 에이전트에 인증이 필요하면 독립적인 브로커를 통해 정확히 필요한 대상과 작업으로 범위를 제한한 단기 자격 증명을 제공하세요. 권장 설정을 참고하세요.

검증

다음과 같이 무해한 검증용 파일을 만드세요.

.env.test
test-key.pem
.aws/credentials
.kube/config

그런 다음 Codex에 다음 작업을 요청하세요.

• 일반 파일을 읽습니다.

• 각 검증용 파일을 읽습니다.

• 하위 디렉터리까지 재귀적으로 시크릿을 검색합니다.

• 명령어 실행 환경을 출력합니다.

• 인접 리포지터리를 읽습니다.

일반 파일 읽기는 성공해야 합니다. 거부된 파일과 인접 리포지터리에는 접근할 수 없어야 하며, 제외한 변수는 명령어 실행 환경에 없어야 합니다.

롤백

이전 프로필을 복원하되, 워크플로우 실패 원인을 조사하는 동안에는 시크릿 파일임이 확실한 대상의 접근 거부 규칙을 유지하세요.

적용 한계

파일시스템 접근을 거부해도 이미 프롬프트에 붙여 넣었거나 읽을 수 있는 소스에 커밋한 시크릿, 커넥터가 반환한 시크릿, 모델이 접근할 수 있는 로그에 기록된 시크릿은 제거되지 않습니다.

git push, 배포, 데이터베이스 마이그레이션, 클라우드 CLI 명령어 등의 작업을 실행하기 전에 승인이 필요할 때 이 레시피를 사용하세요. 어떤 명령어에 검토를 요청하고 어떤 명령어를 금지할지 정한 다음 해당 명령어에 대한 규칙을 설정하세요.

목표

모델이 민감한 명령어를 적절하다고 판단하더라도 실행 전에 항상 승인을 기다리거나 실행 자체를 차단합니다.

설정

1. 승인을 요청할 명령어와 금지할 명령어를 정하세요.

2. 관리자가 강제하는 명령어 규칙을 추가하세요.

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

   요구 사항 규칙은 명령어에 승인을 요구하거나 실행을 금지할 수 있지만, 명령어 실행을 허용할 수는 없습니다. 관리형 설정을 참고하세요.

3. 고위험 프로필에서 셸 래퍼가 민감한 명령어를 가릴 수 있다면 같은 prefix_rules 배열에 셸 래퍼 항목을 추가하세요.

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

   셸 래퍼 항목은 승인 요청을 자주 발생시키므로 필요한 경우에만 사용하세요.

4. 사람이 직접 명령어를 승인해야 한다면 다음 설정을 강제하세요.

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

   자동 검토는 검토 주체를 바꾸며, 특정 보안 결과를 보장하지 않습니다. 자동 검토를 참고하세요.

5. PermissionRequest, 도구 사용 결정, 도구 결과 이벤트를 보안 파이프라인으로 보내세요.

검증

• git status를 실행하세요. 승인 요청이 표시되지 않아야 합니다.

• git push를 실행하세요. 승인 요청이 표시되어야 합니다.

• terraform apply를 실행하세요. 승인 요청이 표시되어야 합니다.

• kubectl delete pod test를 실행하세요. 승인 요청이 표시되어야 합니다.

• rm -rf test-directory를 실행하세요. 명령어 실행이 금지되어야 합니다.

• 승인 요청 하나를 거부하세요. 명령어가 실행되지 않고 거부 사실이 로그에 기록되어야 합니다.

• 클라이언트를 다시 시작하고 검증을 반복하세요. 규칙이 계속 강제되어야 합니다.

롤백

이전 요구 사항 번들을 복원하세요. 토큰 패턴의 범위가 지나치게 넓다면 민감한 명령어 유형 전체를 제거하지 말고 패턴의 범위를 좁히세요.

적용 한계

접두사 규칙만으로 운영체제 정책 전체를 강제할 수는 없습니다. 샌드박스, 최소 권한 OS 계정, 네트워크 제한, 클라우드 IAM, 브랜치 보호, 배포 승인, 데이터베이스 권한 부여를 함께 적용하세요.

사용할 설정 레시피: 권한 프로필과 전체 권한 제한하기, 시크릿 및 작업과 무관한 리포지터리 보호하기, 민감한 명령어에 승인 요구하기.

개발자에게 프로덕션 접근 권한이 있고, Codex가 개발을 지원하되 검토 없이 프로덕션을 변경하지 못하도록 하려는 경우에 사용하세요.

• 승인된 워크스페이스 프로필을 정의하고 허용된 프로필과 승인 정책을 강제하세요. 사용자가 재정의하지 못하도록 관리자가 강제하는 요구 사항으로 배포하세요.

• 권한이 더 낮은 별도 ID로 Codex를 실행하거나 프로덕션 쓰기 자격 증명에 접근하거나 이를 획득할 수 없는 환경에서 실행하세요. 개발자는 별도로 인가된 워크플로우를 통해 프로덕션 접근 권한을 유지할 수 있습니다.

• 하위 프로세스로 실행하는 명령어에 전달되는 환경 변수를 최소화하세요. 에이전트에 인증이 필요하면 독립적인 브로커를 통해 정확히 필요한 대상과 작업으로 범위를 제한한 단기 자격 증명을 제공하세요.

• 승인을 요청할 명령어와 금지할 명령어를 정하세요. git push, terraform apply, Kubernetes 변경, 데이터베이스 마이그레이션처럼 영향이 큰 작업 중 지정한 작업은 사람이 승인하도록 하고, 절대 실행해서는 안 되는 명령어는 금지하세요.

• 프로덕션 IAM, 브랜치 보호, 배포 승인은 Codex와 독립적으로 계속 강제하세요.

권한 프로필 제한 및 사람의 검토 요구

관리자가 관리하는 requirements.toml에서 기본 제공 워크스페이스 프로필과 읽기 전용 프로필을 허용하고, 승인이 필요한 작업에는 사용자 검토를 요구하세요.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

워크스페이스 프로필은 샌드박스 안에서 워크스페이스 작업을 허용합니다. 범위가 더 좁은 작업에는 읽기 전용 프로필을 사용할 수 있습니다. 전체 권한 프로필은 허용 목록에 없습니다.

클라이언트에서 호환되는 정책을 명시적으로 선택해야 한다면 클라이언트 설정에 approval_policy = "on-request"를 지정하세요. on-request는 필요할 때 승인 요청을 표시할 수 있게 하며, 모든 명령어에 승인을 요청하지는 않습니다. 검토가 필요한 작업에는 명시적인 규칙을 추가하고, 프로덕션 권한은 독립적으로 관리하세요.

관리형 프로필 허용 목록을 사용하려면 Codex 0.138.0 이상이 필요합니다. 이전 클라이언트에는 문서에 나온 레거시 샌드박스 모드 요구 사항을 적용하고 테스트하세요.

각 시범 클라이언트를 다시 시작한 다음 승인된 프로필이 작동하고 허용되지 않은 전체 권한 프로필이 거부되는지 확인하세요.

Codex 실행 ID와 프로덕션 자격 증명 분리

기기 관리 시스템이나 개발 환경 프로비저닝 시스템에서 필요한 소스와 개발 서비스에만 접근할 수 있는 Codex 전용 사용자, 컨테이너 또는 개발 호스트를 만드세요. 개발자의 프로덕션 자격 증명 파일, 토큰 헬퍼, 키체인을 해당 환경에 마운트하지 말고, 해당 ID가 프로덕션 쓰기 역할을 획득하지 못하게 하세요.

에이전트에 서비스 접근 권한이 필요하면 조직의 자격 증명 브로커가 해당 개발 리소스와 작업에 한정된 단기 자격 증명을 발급하도록 설정하세요. 개발자는 별도로 인가된 프로덕션 워크플로우에서 평소 사용하는 ID를 사용할 수 있습니다.

예를 들어 AWS IAM에서 역할을 열고 Codex 개발 역할을 선택한 다음 권한에서 아래와 같이 검토를 마친 인라인 정책을 추가하세요. 계정과 역할은 실제 값으로 바꾸세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

이 예시는 지정한 역할을 맡으려는 시도만 거부하며 다른 역할을 맡으려는 시도는 거부하지 않습니다. 직접 부여된 프로덕션 권한도 제거하고, 다른 프로덕션 역할과 자격 증명 출처를 제한하고, 신뢰 정책과 조직 수준의 통제를 검토하세요.

프로덕션을 변경하지 않고 대표적인 개발 및 프로덕션 권한에 대해 개발 역할을 테스트하세요. AWS IAM 역할 정책 예시를 참고하세요.

셸 환경 최소화

시스템 전체의 초기 설정은 /etc/codex/config.toml에서, 개별 사용자 설정은 ~/.codex/config.toml에서 하위 프로세스로 실행하는 명령어가 상속할 환경 변수를 지정하세요.

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

이는 변경할 수 있는 기본값이므로 자격 증명 접근 범위를 강제하지 않습니다. 사용자 설정, 셸 초기화 또는 스냅샷, 자격 증명 헬퍼, 기타 자격 증명 출처를 통해 자격 증명이 여전히 노출될 수 있습니다.

워크플로우와 호환된다면 requirements.toml에 다음 선택적 제한을 추가해 로그인 셸과 셸 스냅샷을 비활성화하세요.

allow_login_shell = false

[features]
shell_snapshot = false

로그인 셸 초기화에 의존하는 워크플로우가 있으므로 이 설정을 먼저 시범 적용하세요.

필터에 일치하는 무해한 테스트용 변수를 설정한 상태로 Codex를 시작하고 하위 프로세스로 실행한 명령어의 환경을 검사하세요. 로그인 셸을 비활성화했다면 로그인 셸 요청이 거부되는지도 확인하세요. 실행 ID가 실제 프로덕션 자격 증명에 접근할 수 없는지도 별도로 검증하세요. 셸 환경 정책을 참고하세요.

영향이 큰 특정 명령어에 승인 요청

조직에서 사용하는 명령어에 대한 요구 사항 규칙을 추가하세요. 예를 들면 다음과 같습니다.

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

절대 실행해서는 안 되는 명령어에는 forbidden을 사용하세요. 실제 배포 및 마이그레이션 도구에 맞게 패턴을 교체하거나 추가하세요.

이 규칙은 명령어 접두사를 검사하므로 동일한 작업을 수행하는 모든 방식을 포괄하지는 않습니다. 절대 경로, 래퍼, 다른 인수 순서, 다른 클라이언트 및 도구를 별도로 테스트하세요.

폐기 가능한 테스트 대상에서 일반 명령어를 실행한 다음 목록에 있는 작업을 요청하세요. 승인 요청을 거부하고 작업이 실행되지 않았는지 확인하세요. 명령어 규칙 강제하기를 참고하세요.

Codex 외부에서 리포지터리 및 배포 승인 강제

소스 제어 플랫폼에서 main과 같은 프로덕션 브랜치를 보호하세요. 변경 사항 검토와 필요한 승인 및 상태 검사를 요구하고, 어떤 역할이 이러한 요구 사항을 우회할 수 있는지 검토하세요. 배포 승인은 해당 배포 시스템에서, 데이터베이스 권한은 데이터베이스 자체에서 설정하세요.

폐기 가능한 리포지터리에서 검토를 마친 변경 사항은 적용되고 인가되지 않은 직접 푸시는 거부되는지 확인하세요. 이 통제는 Codex를 통해 작업을 요청했는지와 관계없이 적용됩니다.

검증

폐기 가능한 테스트 대상에서 다음을 확인하세요.

• 일반적인 워크스페이스 작업을 실행하세요. 작업이 성공해야 합니다.

• 대표적인 민감한 명령어를 시도하고 승인 요청을 거부하세요. 거부된 명령어가 실행되지 않아야 합니다.

• Codex 실행 ID가 프로덕션 쓰기 권한을 획득할 수 없는지 확인하세요.

• 클라이언트를 다시 시작하고 검증을 반복하세요.

적용 한계

접두사 규칙만으로 운영체제 정책 전체를 강제할 수는 없습니다. 샌드박스, 최소 권한 OS 계정, 네트워크 제한, 클라우드 IAM, 브랜치 보호, 배포 승인, 데이터베이스 권한 부여를 함께 적용하세요.

사용할 설정 레시피: 시크릿 및 작업과 무관한 리포지터리 보호하기, 네트워크 접속 대상 제한하기, 승인된 MCP 서버만 허용하기, 민감한 명령어에 승인 요구하기.

개발자가 내부 리포지터리에서 Codex를 사용할 때 코드가 공개 리포지터리, 공개 코드 스니펫 또는 기타 미승인 대상으로 전송될 위험을 줄이려는 경우에 사용하세요.

• 알려진 자격 증명 디렉터리와 관련 없는 리포지터리의 정확한 경로를 거부 대상으로 추가하고, 하위 프로세스로 실행하는 명령어에 전달되는 환경 변수를 최소화하세요.

• 에이전트에 인터넷 접근이 필요하면 승인된 도메인으로 허용 목록을 좁게 구성하세요. 승인된 MCP 서버 이름과 식별 정보만 허용하고, git push 등 지정한 게시 명령어에 검토를 요구하거나 실행을 거부하세요.

• 조직에 적합한 소스 제어 훅과 권한, 공개 리포지터리 및 코드 스니펫 정책, 데이터 유출 방지 통제를 사용하세요.

관련 없는 리포지터리와 자격 증명 파일에 대한 접근 거부

관리자가 관리하는 requirements.toml에 로컬 에이전트가 읽어서는 안 되는 정확한 경로를 추가하세요.

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

예시를 관리 대상 기기에 있는 경로로 바꾸세요. 이 관리형 거부 규칙은 허용된 모든 권한 프로필에 적용됩니다. 특정 사용자 지정 프로필 안에서만 설정한 거부 규칙은 다른 프로필을 선택한 사용자에게 적용되지 않습니다. 알고 있는 정확한 경로를 우선 사용하고, glob 패턴을 사용한다면 필요한 디렉터리 깊이에서 테스트하세요.

네이티브 Windows 환경에서 관리형 deny_read는 파일을 직접 다루는 도구에 적용되지만 그 자체로는 셸 하위 프로세스의 읽기를 막지 못합니다. OS 계정과 파일 접근 제어 목록도 함께 사용하세요.

거부된 위치에 무해한 검증용 파일을 만드세요. 허용된 모든 프로필에서 해당 파일을 직접 읽거나 셸을 통해 읽는 시도가 거부되고 승인된 소스 파일은 읽을 수 있는지 확인하세요. 관리형 읽기 거부 요구 사항을 참고하세요.

자격 증명을 포함하는 셸 변수 최소화

/etc/codex/config.toml 또는 ~/.codex/config.toml에서 상속할 환경 변수의 범위를 좁게 설정하세요.

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

이 설정은 상속되는 변수를 줄이지만 사용자가 변경할 수 있으며, 자격 증명 파일, 자격 증명 헬퍼, 셸 초기화 시 불러오는 내용, 다른 ID에 대한 접근까지 막지는 않습니다.

필요하다면 관리자는 requirements.toml에 다음 제한도 추가하고 시범 적용해 개발자 워크플로우에 미치는 영향을 평가할 수 있습니다.

allow_login_shell = false

[features]
shell_snapshot = false

검증용으로 만든 변수와 별도의 최소 권한 실행 ID로 테스트하세요. 실제 자격 증명은 사용하지 마세요. 셸 환경 정책을 참고하세요.

로컬 명령어에 승인된 네트워크 접속 대상만 허용

샌드박스에서 실행되는 로컬 명령어에 네트워크 접근이 필요하다면 아래 프로필 설정과 관리형 프록시 설정을 모두 requirements.toml에 병합하고 도메인을 승인된 엔드포인트로 바꾸세요.

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

네트워크 사용 프로필은 샌드박스 명령어에 네트워크 접근 경로를 제공하고, 관리형 프록시는 접속 대상을 제한합니다. 두 설정을 함께 배포하세요. 지정한 관리형 프록시 없이 네트워크 사용 프로필만 배포하면 동일한 접속 대상 제한이 적용되지 않습니다. 인터넷 접근이 필요하지 않으면 네트워크 접근을 꺼 두세요.

표준 domains 테이블을 레거시 allowed_domains 또는 denied_domains 설정과 함께 사용하지 마세요. 기존 정책을 마이그레이션하고 테스트하세요.

클라이언트를 다시 시작하고 승인된 엔드포인트에는 접속할 수 있고 승인되지 않은 엔드포인트는 차단되는지 확인하세요.

이 설정은 실험적이므로 OS와 클라이언트의 지원 여부를 검증하세요. 승인된 호스트 이름이 사설 IP 주소로 해석되면 사설 네트워크 접근을 별도로 설정하세요. 샌드박스 제한을 전부 해제하는 권한 상승이 승인되면 명령어 프록시를 우회할 수 있습니다.

이 로컬 명령어용 네트워크 통제만으로는 웹 검색, 앱, MCP 서버, 브라우저 활동, 클라우드 환경을 제어할 수 없으므로 별도 정책이 필요합니다. 승인된 호스팅 도메인에도 공개 리포지터리나 공개 코드 스니펫이 있을 수 있으므로 접속 대상 허용 목록만으로 콘텐츠를 보호할 수는 없습니다. 네트워크 접근 요구 사항을 참고하세요.

클라우드 환경 네트워크 별도 설정

현재 Codex Cloud 인터페이스에서 환경 설정을 여세요. 모든 공용 인터넷 접근 허용과 패키지 관리자 도메인 허용을 끄세요. 공용 인터넷 접근이 필요하면 추가 허용 도메인에 승인된 호스트를 정확히 입력하세요. 승인되지 않은 공용 대상에 대한 접근을 허용하는 HTTP 시크릿을 제거하세요. VPN 외부의 공용 인터넷 접근을 차단하려면 목록을 비워 두고 공용 대상에 대한 접근을 허용하는 HTTP 시크릿을 제거하세요. 설정을 저장하고 환경을 게시하거나 다시 게시한 다음 새 작업을 테스트하세요.

서비스 인증과 기능은 별도로 검토하세요.

레거시 Codex Cloud는 환경별로 별도의 에이전트 인터넷 설정을 사용해 허용 도메인과 HTTP 메서드를 제어합니다. 설정 스크립트에는 별도의 접근 방식이 적용됩니다.

실제로 사용하는 환경 버전을 테스트하세요. 서비스에 연결하기와 레거시 인터넷 설정을 참고하세요.

MCP 서버 제한 및 Git 푸시 전 승인 요청

requirements.toml에서 승인된 로컬 MCP 서버 식별 정보만 허용하세요. 예를 들면 다음과 같습니다.

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

실제 서버는 사용자 설정 또는 관리형 기본값을 제공하는 config.toml에 별도로 설정하세요. 허용 항목과 일치하는 이름 및 URL을 사용하고 서버에 필요한 인증을 구성하세요.

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

요구 사항은 일치하는 서버를 허용할 뿐 서버를 생성하지는 않습니다. 서버 자체의 접근 권한과 도구를 검토하세요.

승인된 서버는 연결할 수 있고 이름이나 URL이 다른 서버는 허용되지 않는지 확인하세요.

대표적인 게시 명령어를 실행하기 전에 검토를 요청하도록 관리형 명령어 규칙을 추가하세요.

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

사람이 직접 검토해야 한다면 최상위 요구 사항으로 allowed_approval_policies = ["on-request"]와 allowed_approvals_reviewers = ["user"]를 함께 설정하세요.

테스트 푸시를 거부하고 실행되지 않는지 확인하세요.

접두사 일치 검사로는 모든 래퍼, API 클라이언트, 앱 또는 다른 게시 경로를 포괄할 수 없습니다.

소스 제어와 DLP 통제로 공개 게시 제한

소스 제어 플랫폼에서 지원하는 경우 공개 리포지터리 생성을 제한하고 리포지터리의 공개 범위를 변경할 수 있는 사용자를 제한하세요. 특권 사용자의 우회 권한을 검토하세요. 조직 설정이 모든 게시 대상에 적용되는 것은 아니므로 개인 계정, 코드 스니펫, 외부 조직, 토큰 접근 권한을 별도로 확인하세요.

해당 리포지터리에서 변경 사항 검토를 필수로 지정하고 브랜치 보호와 우회 권한을 검토하세요.

조직의 DLP 콘솔에서 민감한 소스 코드 콘텐츠와 DLP 제품이 실제로 지원하는 업로드 또는 리포지터리 채널에 시범 정책을 설정하세요. 정책 동작을 차단으로 설정하고 아무 동작도 일으키지 않는 테스트용 표식으로 검증하세요.

소스 제어 플랫폼이 서버 측 통제를 지원한다면 푸시를 받는 리포지터리에 검토를 마친 훅을 설정하고 강제하세요.

인가된 테스트 대상을 사용하고 실제 게시가 이루어지기 전에 차단되는지 확인하세요.

검증

• 무해한 검증용 파일을 만들고 거부된 파일을 읽으려는 시도가 실패하는지 확인하세요.

• 네트워크 접근을 활성화했다면 승인된 대상에는 접속할 수 있고 승인되지 않은 대상은 차단되는지 확인하세요. 비활성화했다면 네트워크 요청이 차단되는지 확인하세요.

• 무해한 표식과 폐기 가능한 테스트 계정 또는 대상을 사용해 대표적인 공개 게시 시도가 실제 게시 전에 차단되는지 확인하세요.

적용 한계

허용된 도메인에서도 공개 콘텐츠를 호스팅할 수 있습니다. 웹 검색, 앱, MCP 서버, 브라우저 활동, Codex Cloud는 별도로 설정하세요. 로컬 샌드박스 규칙은 여기에 적용되지 않습니다.

사용할 설정 레시피: 권한 프로필과 전체 권한 제한하기, 승인된 MCP 서버만 허용하기, 네트워크 접속 대상 제한하기, 시크릿 및 작업과 무관한 리포지터리 보호하기, 민감한 명령어에 승인 요구하기.

Codex가 리포지터리에서 작업하거나 사용자가 로컬 설정을 변경해도 Codex에 적용되는 제한을 유지하려는 경우에 사용하세요.

• 지원되는 권한, 승인, MCP, 네트워크, 명령어 제한을 관리자가 강제하는 요구 사항으로 배포하세요.

• 훅 스크립트를 관리자가 관리하는 디렉터리에 설치하세요. 사용자, 프로젝트, 플러그인 훅을 무시해야 한다면 관리형 훅만 사용하세요.

• 운영체제와 기기 관리 수단으로 정책 파일과 설정 배포 경로를 보호하세요. 이러한 보호 조치를 변경할 수 있는 특권 없이 Codex를 실행하세요.

• 적용 대상인 각 클라이언트와 환경에서 실제로 적용된 설정을 검토하세요.

허용된 프로필, 승인 방식, 서버 식별 정보, 명령어 강제

사용자나 리포지터리에서 편집할 수 있는 설정에 의존하지 말고 검토를 마친 설정을 관리자가 관리하는 requirements.toml에 병합하세요. 예를 들면 다음과 같습니다.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

이 예시는 두 가지 프로필을 허용하고, 승인이 필요할 때 사람의 검토를 요구하며, 식별 정보가 일치하는 MCP 서버를 허용하고, 특정 접두사로 시작하는 명령어에 승인을 요청합니다.

MCP 서버 자체는 별도로 설정하고 조직에서 사용하는 다른 민감한 명령어 패턴도 추가하세요. 필요에 따라 전역 파일 제한과 네트워크 제한을 추가하세요. 요구 사항은 지원되는 설정을 제한하지만 Codex 외부에서 ID, 서비스, 접속 대상을 통제하는 수단을 대신할 수는 없습니다.

관리형 프로필 허용 목록을 사용하려면 Codex 0.138.0 이상이 필요합니다.

시범 클라이언트에서 허용되지 않은 프로필 선택, 제한된 사용자 또는 프로젝트 설정 변경, 허용 목록에 없는 MCP 식별 정보 사용을 시도하세요. 각 시도가 거부되거나 재시작 후에도 제한이 유지되는지 확인하세요. 테스트 명령어의 승인 요청을 거부하고 명령어가 실행되지 않는지 확인하세요.

관리형 파일시스템 및 네트워크 제한 추가

허용된 모든 프로필에서 민감한 로컬 파일 읽기를 거부하려면 requirements.toml에 다음 테이블을 추가하고 예시를 조직의 경로로 바꾸세요.

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

샌드박스에서 실행되는 로컬 명령어에 네트워크 접근이 필요하면 네트워크 사용이 허용된 프로필과 관리형 접속 대상을 함께 정의하세요.

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

앞서 지정한 :workspace 기본값 대신 이 프로필 정책을 선택하거나, 두 프로필을 모두 사용할 계획이라면 두 이름을 병합하세요. 키나 테이블을 중복해서 붙여 넣지 마세요. 명령어에 네트워크가 필요하지 않으면 비활성화 상태로 두세요.

무해한 파일을 사용해 지정한 경로에서 읽기가 거부되는지 확인하고, 승인된 접속 대상과 승인되지 않은 접속 대상을 각각 검증하세요.

네이티브 Windows 환경에서는 관리형 deny_read만으로 셸 하위 프로세스의 읽기를 막을 수 없으므로 파일 접근 제어 목록도 사용하세요.

로컬 명령어의 네트워크 설정은 다른 클라이언트, 앱, 커넥터, 클라우드에서의 실행에 적용되지 않습니다.

관리자가 관리하는 훅 설치 및 강제

관리자가 검토를 마친 훅 프로그램을 root가 관리하는 디렉터리에 설치하도록 하세요. 예시 설치 경로는 /etc/codex/hooks/pre_tool_use_policy.py입니다. Codex 사용자가 파일이나 해당 디렉터리를 변경하지 못하게 하세요. requirements.toml에서 훅을 활성화하고 사용자, 프로젝트, 세션, 플러그인 훅은 무시하도록 설정하세요.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

이 요구 사항은 훅을 등록하지만 설치하지는 않습니다. 로컬 macOS 통합 테스트를 위해 다음 코드를 pre_tool_use_policy.py로 저장하고 관리자가 아래 명령어로 설치하도록 하세요.

이 코드는 테스트용 표식만 차단합니다. 실제 보호 수단으로 사용하기 전에 검토를 마친 조직별 정책으로 교체하세요. 대상 기기에 /usr/bin/python3가 있는지 확인하고 필요한 경우 인터프리터 경로를 조정하세요.

1
2
3
4
5
6
7
8import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

로컬 클라이언트를 다시 시작한 다음 아래 항목을 확인하세요.

• 무해한 Bash 명령어가 실행되는지 확인하세요.

• CODEX_HOOK_TEST_DENY가 포함된 명령어가 차단되는지 확인하세요.

• Codex 사용자가 정책과 종속성을 변경할 수 없는지 확인하세요.

allow_managed_hooks_only는 관리 대상이 아닌 사용자, 프로젝트, 세션, 플러그인 훅을 모두 건너뛰므로 다른 워크플로우에 영향을 줄 수 있습니다.

Bash 일치 규칙은 모든 도구나 기존 프로세스에 나중에 전달되는 입력까지 검사하지는 않습니다. 오류, 시간 초과 또는 형식이 잘못된 훅 응답이 발생하면 도구 호출이 그대로 진행될 수 있습니다.

클라우드에서 오케스트레이션되는 Work 모드에서는 지원되는 훅 핸들러가 다릅니다. OS와 서비스의 독립적인 보호 조치를 유지하세요. 관리형 훅과 훅 동작을 참고하세요.

정책과 배포 경로 보호

macOS에서는 관리자가 검토와 병합을 마친 요구 사항 파일을 root 소유의 상위 디렉터리에 배포하고 Codex 사용자가 파일에 쓰지 못하도록 할 수 있습니다.

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Linux에서는 적절한 관리자 그룹을 사용하세요. Windows에서는 관리자가 관리하는 접근 제어 목록으로 ProgramData 디렉터리와 파일을 보호하세요. MDM 또는 클라우드 정책을 변경할 수 있는 사용자를 제한하고 변경 사항을 검토하며 롤백용 사본을 보관하세요.

관리자 권한이 없는 시범 계정으로 정책, 상위 디렉터리, 관리형 훅 프로그램을 수정할 수 없는지 확인하세요. 제한이 더 약한 사용자 또는 프로젝트 설정을 시도한 후 Codex를 다시 시작해 강제한 동작이 유지되는지 확인하세요.

모든 클라이언트가 같은 정책을 불러온다고 가정하지 말고 적용 대상인 각 클라이언트와 환경에서 테스트하세요.

검증

관리자 권한이 없는 테스트 ID로 다음을 확인하세요.

• 관리형 정책을 편집해 보세요. 관리형 파일을 변경할 수 없어야 합니다.

• 사용자 또는 프로젝트 설정으로 제한을 완화해 보세요. 더 약한 설정이 거부되거나 기존 제한 범위 안에서만 적용되어야 합니다.

• 클라이언트를 다시 시작하고 제한이 계속 적용되는지 확인하세요.

적용 한계

호스트에서 충분한 관리자 권한을 가진 사용자나 에이전트는 주변 보호 조치를 변경할 수 있습니다. 사용자가 편집할 수 있는 설정만으로는 관리자가 관리하는 요구 사항을 대체할 수 없습니다.