Codex 보안 가이드

직원이 회사의 ChatGPT 워크스페이스를 통해 Codex에 로그인해야 하며, 관리형 엔드포인트에서 개인 ChatGPT 계정과 API key 인증을 금지해야 하는 경우 이 레시피를 사용하세요.

목표 결과

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

사전 요구 사항

• 승인된 ChatGPT Enterprise 워크스페이스의 UUID.

• Codex 관리형 구성을 엔드포인트에 배포할 방법.

• 관리형 엔드포인트에서 API key 인증을 금지한다는 결정.

구성

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 key 로그인을 시도하세요. 예상 결과: API key 로그인이 거부됩니다.

• 회사 계정으로 승인된 워크스페이스에 로그인하세요. 예상 결과: 로그인에 성공합니다.

• 데스크톱 앱, 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 server를 결정하고 승인된 목록을 강제해야 하는 경우 이 레시피를 사용하세요.

서버 허용과 서버 구성은 별도의 단계입니다. 허용 목록 항목은 일치하는 서버를 허용할 뿐, 서버 구성을 생성하지는 않습니다. 일치하는 이름과 ID, 필요한 인증을 사용하여 서버를 별도로 구성하세요.

목표 결과

Codex는 구성된 이름과 ID가 엔터프라이즈 승인 목록과 일치하는 MCP server만 활성화합니다.

구성

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

2. 모두 거부하는 상태에서 시작하세요. 빈 관리형 테이블은 모든 MCP server를 비활성화합니다.

   [mcp_servers]

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

   [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 ID는 plugins.<plugin>.mcp_servers.<server> 아래에 별도로 추가하세요.

6. 승인 목록을 검토된 구성 저장소에 보관하고 관리자가 강제하는 요구 사항을 통해 배포하세요.

클라이언트는 서버의 이름과 ID가 모두 승인된 항목과 일치할 때만 서버를 활성화합니다. 관리형 구성을 확인하세요.

검증

• 승인된 서버를 정확하게 구성하세요. 예상 결과: 서버가 시작됩니다.

• URL의 한 글자를 바꾸세요. 예상 결과: 서버가 비활성화됩니다.

• stdio 인수 개수나 순서를 바꾸거나, 구성된 인수 규칙을 벗어나는 인수를 제공하세요. 예상 결과: 서버가 비활성화됩니다. 허용된 접두사 조건을 여전히 충족하는 값은 계속 허용됩니다.

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

• 승인되지 않은 이름을 추가하세요. 예상 결과: 서버가 비활성화됩니다.

• 플러그인에 번들로 포함된 서버를 테스트하세요. 예상 결과: 승인된 ID로만 서버가 작동합니다.

롤백

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

적용 범위와 한계

ID 허용 목록은 서버의 도구, 업스트림 데이터, 자격 증명, 실행 환경이 안전하다는 것을 입증하지 않습니다. 로컬 stdio MCP 프로세스는 로컬 명령 샌드박스 밖에서 실행됩니다. 실행 파일과 인수의 일치 여부를 검사해도 서버의 접근 권한을 제한하거나 환경 기반 코드 로딩을 방지하지는 못합니다. 전체 실행 컨텍스트와 서버 권한을 독립적으로 검토하세요. MCP ID 요구 사항을 확인하세요.

보안팀이 엔드포인트와 네트워크에서 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 server, 브라우저 활동, Codex Cloud에 대한 텔레메트리를 별도로 구성하세요. 로컬 명령 프록시 규칙은 이들을 자동으로 포괄하지 않습니다.

7. 지원되는 Compliance API 기록을 SIEM으로 스트리밍하고 조직의 보존 및 법적 보존 제어를 적용하세요. Compliance API 및 감사 이벤트를 확인하세요.

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

검증

다음 작업을 수행하는 통제된 세션을 실행하세요.

• 허용된 파일 하나를 읽습니다.

• 차단된 파일 읽기를 한 번 시도합니다.

• 허용된 명령 하나를 실행합니다.

• 차단된 아웃바운드 요청을 한 번 시도합니다.

• 승인을 요청하고 거부 응답을 받습니다.

• 세션을 종료합니다.

증거 소스별 예상 결과:

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

• 훅에 세션 수명 주기가 표시됩니다.

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

• Compliance 수집 파이프라인에서 지원되는 기록을 수신합니다.

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

롤백

이전 구성을 복원하여 내보내기 도구와 훅을 비활성화하세요. 텔레메트리 롤백 과정에서 독립적인 프록시 로깅을 제거하지 마세요.

적용 범위와 한계

Codex 텔레메트리가 모든 명령 인수, 출력 바이트, 네트워크 패킷을 캡처한다고 보장하지 마세요. 각 계층의 수집 범위를 문서화하세요.

Codex의 인터넷 접근을 차단하거나 승인된 대상에만 접근하도록 해야 하는 경우 이 레시피를 사용하세요. 구성하는 환경에 맞게 로컬 또는 클라우드 절차를 선택하고, 각 정책의 적용 범위가 다르다는 점을 염두에 두세요.

목표 결과

선택한 구성에 따라 Codex의 인터넷 접근이 차단되거나 승인된 도메인에만 접근할 수 있습니다. Codex Cloud (Legacy) 환경에서는 HTTP 메서드도 추가로 제한할 수 있습니다.

현재 Codex Cloud 구성

1. no-internet-review, approved-dependencies-build, cyber-lab 등 신뢰 수준별로 별도의 환경을 만드세요.

2. 환경 구성에서 워크플로에 인터넷 접근이 필요하지 않다면 Codex의 인터넷 접근 허용 을 꺼 두세요.

3. 접근이 필요하면 Codex의 인터넷 접근 허용 을 켜세요. 도메인 허용 에서 사용자 지정 도메인만 을 선택한 다음 추가 허용 도메인 에 필요한 정확한 호스트를 추가하세요.

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

서비스에 연결을 확인하세요. 현재 Codex Cloud 설정에는 Legacy의 HTTP 메서드 선택기가 없습니다.

Codex Cloud (Legacy) 구성

1. 에이전트의 인터넷 접근이 필요하지 않다면 끄기 로 유지하세요. Legacy Cloud는 기본적으로 에이전트 단계에서 인터넷을 차단하지만, 설정 스크립트는 종속성 설치를 위해 인터넷에 접근할 수 있는 상태로 실행됩니다.

2. 에이전트 접근이 필요하면 범위를 좁힌 허용 목록과 함께 켜기 로 설정하세요. 없음 에서 시작하여 정확한 도메인을 추가하세요.

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

레거시 에이전트 인터넷 접근을 확인하세요. 이 사전 설정과 HTTP 메서드 제어는 Legacy Cloud에만 적용됩니다.

로컬 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 server, 브라우저 활동, Codex Cloud는 별도로 구성하세요. 로컬 샌드박스 규칙은 이들을 제어하지 않습니다.

검증

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

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

• localhost, 사설 IP, 클라우드 메타데이터 엔드포인트로 요청을 보내세요. 명시적으로 승인되지 않은 한 각 요청이 차단되는지 확인하세요.

• Codex Cloud (Legacy)에서 허용된 도메인으로 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. Cloud 환경에 맞는 자격 증명 흐름을 선택하세요.

   • 현재 Codex Cloud에서는 허용된 HTTPS 서비스로 보내는 자격 증명에 네트워크 비밀 정보 를 사용하세요. 프로그램은 플레이스홀더를 전달받으며, 프록시가 설정 및 작업 중에 포트 443의 승인된 대상에 대해 이를 실제 값으로 대체합니다. 원본 자격 증명은 로컬 프로세스나 파일에 배치되지 않습니다. 직접 설정한 환경 변수는 프로그램에서 접근할 수 있습니다. 환경 변수 및 네트워크 비밀 정보를 확인하세요.
   • Codex Cloud (Legacy)에서 비밀 정보는 설정 시 인증을 지원하며 에이전트 단계 전에 제거됩니다. 환경 변수는 전체 채팅 동안 유지됩니다. 레거시 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, tool-decision, tool-result 이벤트를 보안 파이프라인으로 전송하세요.

검증

• 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를 시작하고 생성된 명령의 환경을 검사하세요. 로그인 셸을 비활성화했다면 로그인 셸 요청이 거부되는지도 확인하세요. 실행 주체가 실제 프로덕션 자격 증명에 접근할 수 없는지도 별도로 확인하세요. 셸 환경 정책을 참조하세요.

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

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

[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 실행 주체가 프로덕션 쓰기 권한을 얻을 수 없는지 확인합니다.

• 클라이언트를 다시 시작하고 반복합니다.

한계

접두사 규칙은 완전한 운영 체제 정책 엔진이 아닙니다. 샌드박싱, 최소 권한 OS 계정, 네트워크 제한, 클라우드 IAM, 브랜치 보호, 배포 승인 및 데이터베이스 권한 부여와 함께 사용하세요.

사용하는 구성 예시: 비밀 정보 및 관련 없는 저장소 보호; 네트워크 대상 제한; 승인된 MCP server만 허용; 민감한 명령에 승인 요구.

개발자가 내부 저장소에서 Codex를 사용하며, 코드가 공개 저장소, 공개 코드 스니펫 또는 기타 승인되지 않은 대상으로 전송될 위험을 줄이려는 경우입니다.

• 알려진 자격 증명 디렉터리와 관련 없는 저장소의 정확한 경로를 거부 목록에 추가하고, 생성된 명령에 전달되는 환경 변수를 최소화하세요.

• 에이전트에 인터넷 접근이 필요하면 승인된 도메인만 포함하는 좁은 허용 목록을 사용하세요. 승인된 MCP server 이름과 ID만 허용하고, 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"

이 설정은 상속되는 변수를 줄이지만 사용자가 변경할 수 있으며, 자격 증명 파일, 도우미, 셸 시작 구성 또는 다른 실행 주체에 대한 접근을 막지는 않습니다.

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

allow_login_shell = false

[features]
shell_snapshot = false

합성 카나리아 변수와 별도의 최소 권한 실행 주체를 사용하여 테스트하세요. 실제 자격 증명을 사용하지 마세요. 셸 환경 정책을 참조하세요.

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

로컬 샌드박스 명령에 네트워크 접근이 필요하면 아래의 프로필 설정과 관리형 프록시 설정을 모두 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 및 클라이언트 지원 여부를 검증하고, 승인된 호스트가 비공개 주소로 확인되는 경우 사설 네트워크 접근을 별도로 구성하세요. 승인된 전체 샌드박스 권한 상승은 명령 프록시를 우회할 수 있습니다.

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

클라우드 환경 네트워킹 별도 구성

현재 Codex Cloud 인터페이스에서 환경 구성을 여세요. Codex의 인터넷 접근 허용 을 꺼 둡니다. 인터넷 접근이 필요하면 이 옵션을 켜고 사용자 지정 도메인만 을 선택한 다음, 추가 허용 도메인 에 필요한 정확한 호스트를 추가하세요. 그런 다음 구성을 저장하고 환경을 게시하거나 다시 게시한 후 새 작업을 테스트하세요.

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

레거시 Codex Cloud는 환경별로 별도의 에이전트 인터넷 설정을 사용하며, 허용 도메인과 HTTP 메서드를 제어할 수 있습니다. 설정 스크립트에는 별도의 접근 동작이 적용됩니다.

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

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

requirements.toml에서 승인된 로컬 MCP server ID만 허용하세요. 예를 들면 다음과 같습니다.

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

일치하는 이름과 URL, 서버에서 요구하는 인증을 사용하여 사용자 또는 관리형 기본 config.toml에서 실제 서버를 별도로 구성하세요.

[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 server, 브라우저 활동 및 Codex Cloud는 별도로 구성하세요. 로컬 샌드박스 규칙은 이를 제어하지 않습니다.

사용하는 구성 예시: 권한 프로필 및 Full Access 제한; 승인된 MCP server만 허용; 네트워크 대상 제한; 비밀 정보 및 관련 없는 저장소 보호; 민감한 명령에 승인 요구.

Codex가 저장소에서 작업하거나 사용자가 로컬 구성을 변경하더라도 Codex에 적용되는 제한이 유지되도록 하려는 경우입니다.

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

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

• 운영 체제 및 기기 관리 제어로 정책 파일과 구성 배포 경로를 보호하세요. 이러한 보호를 변경하는 데 필요한 권한 없이 Codex를 실행하세요.

• 범위에 포함된 각 클라이언트와 환경의 유효 구성을 검토하세요.

허용된 프로필, 승인, 서버 ID 및 명령 강제

사용자나 저장소에서 편집할 수 있는 설정에 의존하지 말고, 검토된 설정을 관리자가 관리하는 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 ID를 허용하고, 특정 명령 접두사에 대해 승인을 요청합니다.

MCP server 자체는 별도로 구성하고 조직의 다른 민감한 명령 패턴을 추가하세요. 필요한 경우 전역 파일 제한과 네트워크 제한을 추가하세요. 요구 사항은 지원되는 설정을 제한하지만, Codex 외부의 실행 주체, 서비스 및 대상 제어를 대체할 수는 없습니다.

관리형 프로필 허용 목록에는 Codex 0.138.0 이상이 필요합니다.

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

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

허용된 모든 프로필에서 민감한 로컬 파일에 대한 접근을 거부하려면 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만으로 셸 하위 프로세스의 읽기를 제어할 수 없으므로 파일 접근 제어 목록도 사용하세요.

로컬 명령의 네트워킹 설정은 다른 클라이언트, 앱, 커넥터 또는 클라우드 실행을 통제하지 않습니다.

관리자 관리 훅 설치 및 강제

관리자가 /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이 있는지 확인하고 필요한 경우 인터프리터 경로를 조정하세요.

import 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에서는 관리자가 검토 및 병합된 요구 사항 파일을 루트 소유 상위 디렉터리에 배포하고 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를 다시 시작한 후 강제된 동작이 유지되는지 확인하세요.

모든 클라이언트가 같은 정책을 로드한다고 가정하지 말고 범위에 포함된 각 클라이언트와 환경을 테스트하세요.

검증

관리자가 아닌 테스트 실행 주체를 사용하여 다음을 수행하세요.

• 관리형 정책 편집을 시도합니다. 예상 결과: 관리형 파일을 변경할 수 없습니다.

• 사용자 또는 프로젝트 구성을 통해 제한을 완화하려고 시도합니다. 예상 결과: 더 약한 설정이 거부되거나 기존 제한이 유지됩니다.

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

한계

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