관리형 구성

관리형 구성을 통해 기업 관리자는 ChatGPT Work와 Codex에서 지원되는 요구 사항과 기본값을 설정할 수 있습니다. 요구 사항은 사용자와 작업이 할 수 있는 일을 제한합니다. 기본값은 초기 값을 제공합니다. 지원 여부는 제품, 클라이언트 버전, 실행 환경에 따라 다릅니다.

지원되는 클라우드 관리 설정은 관리 콘솔의 에이전트 보안 에서 설정합니다. 일반적인 작업에는 설정 컨트롤을 사용하고, 구성 텍스트를 확인하거나 복사하거나 편집하려면 TOML로 편집 을 선택하세요. 두 보기 모두 동일한 정책을 편집합니다. TOML에서는 전용 컨트롤이 없는 지원 필드도 설정할 수 있습니다. 클라우드 관리 설정을 사용하기 위해 로컬 파일을 배포할 필요는 없습니다. 인증 제한과 기기 관리형 배포에는 별도의 로컬 설정이 필요합니다.

Enterprise 관리자는 다음을 통해 지원되는 로컬 클라이언트 동작을 제어할 수 있습니다.

• 요구 사항: 관리자가 적용하며 사용자가 재정의할 수 없는 제약 조건입니다.

• 구성 기본값: 시스템 또는 클라우드에서 관리하는 config.toml 설정으로, 사용자가 재정의할 수 있습니다.

• 레거시 관리형 기본값: 지원되는 클라이언트가 시작될 때 적용되는 managed_config.toml 초기 값입니다. 사용자는 실행 중에도 설정을 변경할 수 있습니다. 클라이언트는 다음에 시작할 때 이 기본값을 다시 적용합니다.

Global 기준 정책, 환경별 재정의, 오케스트레이터 및 실행기 필드 목록은 Agent Security를 참조하세요.

에이전트 보안에서 정책 구성하기

에이전트 보안이 활성화된 경우 워크스페이스 소유자, 워크스페이스 관리자, Codex 관리자 권한이 있는 구성원이 정책을 관리할 수 있습니다. 정책 편집기에 액세스할 수 있다고 해서 해당 정책이 제어하는 기능에 대한 액세스 권한이 구성원에게 부여되는 것은 아닙니다.

워크스페이스의 기준 설정에는 워크스페이스 기본값 을 사용하세요. 특정 사용자, 그룹 또는 역할에 다른 설정이 필요한 경우 재정의 를 사용하세요. 대상 재정의는 정책을 적용받을 대상을 선택하며, 환경 설정은 지원되는 실행 제어가 적용될 위치를 선택합니다.

1. 관리 콘솔 > 에이전트 보안 을 열고 워크스페이스 기본값 또는 재정의 에서 편집하려는 정책을 선택하세요.
2. 강제 적용할 제한을 설정하려면 요구 사항 을 열고, 구성원이 해당 제한 내에서 변경할 수 있는 초기 값을 설정하려면 기본값 을 여세요.
3. 승인, 웹 검색 및 기타 에이전트 전체 설정은 전역 에 유지하세요. 사용 가능한 경우 해당 카드에서 환경 설정 추가 를 사용하여 로컬 환경 또는 Codex Cloud 환경 을 추가하고 지원되는 실행 설정을 구성하세요. 비어 있는 환경 문서는 전역 설정을 상속하며, 현재 기준 설정을 복사하거나 고정하지 않습니다.
4. 이 가이드에 설명된 컨트롤을 사용하세요. 고급 필드의 경우 TOML로 편집 을 선택하고 해당 범위의 requirements.toml 또는 config.toml을 편집하세요. 시각적 편집기로 돌아가려면 설정 컨트롤 사용 을 선택하세요.
5. 유효성 검사 메시지를 검토한 다음 변경 사항 저장 을 선택하세요. 규칙 편집기에서 규칙을 적용하면 초안이 업데이트되지만, 정책 자체가 저장되지는 않습니다.
6. 관리자 및 직원 경험 확인에 설명된 대로 정책 선택과 지원되는 클라이언트 동작을 확인하세요.

환경 편집기와 지원되는 필드는 워크스페이스 및 정책에 따라 다릅니다. 설정 적용 범위를 참조한 후 전역 설정을 환경으로 옮기세요. 전역의 설정이 모든 제품이나 실행 경로에 적용되는 것은 아닙니다.

구성 복사 또는 재사용하기

시각적 편집기가 TOML을 대체하는 것은 아닙니다. TOML로 편집 을 선택하여 구성을 복사하거나, 참조용 사본을 보관하거나, 다른 정책에서 설정을 재사용할 수 있습니다. 시각적 편집기로 돌아가려면 설정 컨트롤 사용 을 선택하세요.

1. 원본 정책을 열고 TOML로 편집 을 선택하세요.
2. 복사할 범위인 전역 또는 사용 가능한 환경 탭을 선택하세요. 재사용하려는 항목에 따라 요구 사항(requirements.toml), 기본값 (config.toml) 또는 둘 다에서 텍스트를 복사하세요.
3. 대상 정책을 열고 TOML로 편집 을 선택한 다음 일치하는 범위를 선택하세요. 요구 사항은 requirements.toml에, 기본값은 config.toml에 붙여 넣으세요. 텍스트를 바꾸기 전에 대상의 기존 설정을 검토하고, 계속 적용해야 하는 관련 없는 설정은 유지하세요.
4. 유효성 검사 메시지와 대상 정책의 적용 대상 및 우선순위를 검토한 다음 변경 사항 저장 을 선택하세요. 복사한 정책을 실제로 사용하기 전에 적용 결과에 따른 클라이언트 동작을 확인하세요.

복사한 텍스트에는 해당 정책과 범위에 작성된 설정이 포함됩니다. 할당, 정책 순서, 다른 환경 문서 또는 다른 정책 및 기기 설정을 결합한 실제 적용 구성은 포함되지 않습니다. 필요한 경우 환경 설정을 별도로 복사하세요. 보기를 전환하거나 텍스트를 복사해도 정책 변경 사항은 저장되지 않습니다.

아래 예제를 사용해 보세요. 설정을 변경한 다음 TOML로 편집 을 선택하여 해당 구성을 확인하세요. 설정 컨트롤 사용 으로 돌아가 계속 시험해 볼 수 있습니다.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

적절한 컨트롤 선택하기

브라우저 및 Computer Use 제어하기

관리 콘솔의 에이전트 보안 을 사용하여 지원되는 데스크톱 클라이언트의 브라우저 및 네이티브 앱 액세스를 관리하세요. UI 컨트롤부터 사용하세요. 아래 TOML 예제는 파일 기반 정책 배포 및 TOML 편집기가 필요한 설정에 대한 구성 참조 자료를 제공합니다.

Browser Use는 브라우저에서 에이전트가 수행하는 활동을 제어합니다. Computer Use는 네이티브 데스크톱 앱에서 에이전트가 수행하는 활동을 제어합니다. 내장 브라우저 패널의 설정은 Browser Use와 별개입니다. 브라우저 세션 및 기존 로그인을 참조하여 브라우저 경로 간의 차이를 확인하세요.

시작하기 전에

에이전트 보안 정책을 관리할 권한이 있는 계정을 사용하세요. 정책이 적용되는 대상과 지원해야 하는 클라이언트 버전 및 운영 체제를 확인하세요. 정책 할당, 전역 설정 및 지원되는 환경 재정의에 대해서는 에이전트 보안을 참조하세요.

사용자가 재정의할 수 없는 제한에는 요구 사항 을 사용하세요. 기본값 은 해당 제한 내에서 초기 값을 설정합니다. 사이트나 앱을 허용해도 플러그인이 설치되거나, 운영 체제 권한이 부여되거나, 사용자가 로그인되거나, 검토가 필요한 작업이 승인되는 것은 아닙니다.

데스크톱 기능 사용 가능 여부 에서 브라우저 사용, 외부 브라우저 사용, 컴퓨터 사용 을 검토합니다. 강제 끄기 는 해당 기능을 비활성화하며, 사이트나 앱의 허용 규칙으로 이를 재정의할 수 없습니다. 전체 CDP 액세스 는 별도로 검토합니다. 사용자 활성화 차단 은 사용자가 이 기능을 활성화하지 못하게 합니다.

이 데스크톱 제어 설정은 호스팅되는 Work Cloud 브라우저를 구성하지 않습니다. 클라우드 브라우저 사용 과 클라우드 네트워크 액세스 는 관리자 콘솔 > 권한 및 역할 > 워크스페이스 기능 > 클라우드 컴퓨터 기능 에서 별도로 관리합니다. Agent Security가 Work Cloud에 적용되는 방식을 참조하세요.

브라우저 액세스 구성

1. 관리자 콘솔 > 에이전트 보안 을 엽니다. 워크스페이스의 기본 정책에는 워크스페이스 기본값 을 사용하거나, 재정의 에서 해당 정책을 엽니다. 요구 사항 에서 데스크톱 브라우저 제어 로 이동합니다.
2. 사이트 규칙 에서 기본값 행의 작업 메뉴를 열고 기본값 편집 을 선택합니다. 승인된 사이트로만 액세스를 제한하려면 사이트 액세스 를 차단 으로 설정한 다음 규칙 적용 을 선택합니다. 일치하는 사이트 규칙에서 기본 규칙 사용 으로 남겨 둔 설정에는 기본값 행의 값이 적용됩니다.
3. 사이트 규칙 추가 를 선택합니다. 사이트 또는 패턴 에 스킴, 호스트 이름, 선택적 포트로 구성된 출처를 입력합니다. 예를 들어 https://example.com은 유효하지만, https://example.com/files는 유효하지 않습니다. 경로, 쿼리 또는 프래그먼트를 포함하지 마세요. HTTP와 HTTPS는 서로 다른 출처입니다. 포트가 스킴의 기본 포트와 다르면 포트를 지정합니다.
4. 사이트 액세스 를 설정하고 다운로드, 업로드, 디버그/CDP 를 검토합니다. 필요에 따라 허용 또는 차단 을 선택하거나, 설정을 기본 규칙 사용 으로 유지합니다. 디버그/CDP 는 브라우저 디버깅을 위한 전체 Chrome DevTools Protocol 액세스를 제어합니다. 허용 을 선택하면 일반적인 정책 및 승인 검사가 계속 진행됩니다.
5. 사이트의 자동 검토, 항상 허용, 승인 유지 기간 을 검토합니다. 승인 유지 기간 에는 이번 턴 과 이 스레드 옵션이 있습니다. 데스크톱 브라우저 제어 의 브라우저 기록, 사이트 승인 저장, 요청 자동 승인 도 검토합니다.
6. 규칙 추가 를 선택하고 유효성 검사 메시지를 검토한 다음 변경 사항 저장 을 선택합니다. 정책을 수신하는 지원 클라이언트에서 허용된 사이트와 차단된 사이트를 테스트합니다. 업로드, 다운로드 및 기타 제한된 작업은 별도로 테스트합니다.

사이트 규칙 추가

사이트 규칙에서 권한을 기본값으로 유지하면 기본값 행이 적용됩니다. 규칙이 겹치면 각 권한에 대해 차단이 우선합니다.

사이트 또는 패턴 

사이트 액세스기본 규칙 사용

다운로드기본 규칙 사용

업로드기본 규칙 사용

디버그/CDP기본 규칙 사용

자동 검토기본 규칙 사용

항상 허용기본 규칙 사용

승인 유지 기간기본 규칙 사용

브라우저 작업의 자동 검토를 비활성화하면 대신 해당 작업이 사용자에게 전송되어 승인을 받습니다. 모델 안전 모니터링은 비활성화되지 않습니다.

여러 출처 패턴이 일치하면 각 설정에 대해 가장 제한적인 값이 우선합니다. 로컬 구성으로 관리형 차단을 완화할 수 없습니다. 관리형 네트워크 차단과 허용 목록 외 모든 항목 차단도 브라우저 도구에 적용됩니다. 출처 패턴과 승인 동작은 브라우저 정책 필드를 참조하세요.

Computer Use는 브라우저를 네이티브 앱으로 조작할 수도 있습니다. Browser Use의 사이트 및 기능 규칙은 이 방식에 적용되지 않습니다. 네이티브 앱 액세스는 별도로 검토하세요. 브라우저 보안 경계를 참조하세요.

네이티브 앱 액세스 구성

1. 요구 사항 에서 데스크톱 앱 제어 > 앱 규칙 으로 이동합니다.
2. 기본값 행의 작업 메뉴를 사용하여 일치하는 규칙이 없는 앱의 액세스를 구성합니다. Computer Use를 승인된 앱으로 제한하려면 기본적으로 액세스를 차단하고 해당 앱에 대한 허용 규칙을 추가합니다.
3. 앱 규칙 추가 를 선택합니다. 규칙 편집 대화 상자의 앱 에서 macOS 번들 ID, Windows AUMID 또는 Windows 실행 파일 을 선택합니다. 번들 ID 또는 Application User Model ID (AUMID)의 정확한 앱 식별자 를 입력합니다. Windows 실행 파일 의 경우 게시자 이름 과 제품 이름 을 입력합니다. 바이너리 이름 은 선택 사항입니다. 표시 이름이나 파일 경로 대신 검증된 앱 식별 정보를 사용합니다.
4. 규칙의 앱 액세스 를 설정한 다음 규칙 추가 를 선택합니다. 데스크톱 앱 제어 의 앱 승인 저장 을 검토하고 유효성 검사 메시지를 확인한 다음 변경 사항 저장 을 선택합니다. 승인 저장을 비활성화해도 현재 세션에 대한 승인은 허용됩니다. 승인 저장을 허용하는 것만으로 앱이 승인되지는 않습니다.
5. 배포 환경의 각 지원 운영 체제에서 허용된 앱과 차단된 앱을 테스트합니다. 운영 체제 권한이 여전히 적용되며 사용자가 필요한 승인을 계속 제공해야 하는지 확인합니다.

규칙 편집

기본 앱 액세스를 설정하고 일치하는 앱에 대해 이를 재정의합니다.

앱macOS 번들 ID

앱 식별자 

앱 액세스액세스 선택

Windows 식별 정보 요구 사항은 Computer Use 정책 필드를 참조하고, 관리형 Mac에 대해서는 잠금 상태 사용 제한을 참조하세요.

실제 적용되는 정책 확인

허용된 사이트나 앱이 여전히 차단된다면 다른 일치 규칙, 정책 할당 및 우선순위, 기기 요구 사항, 사용자 구성을 확인합니다. 한 소스의 허용 규칙으로 다른 적용 가능한 차단을 우회할 수 없습니다. 요구 사항의 위치 및 우선순위를 참조하세요.

설정이 적용되지 않으면 클라이언트, 운영 체제 및 정책 전달 경로가 해당 설정을 지원하는지 확인합니다. 로컬 컴퓨터 액세스를 사용하는 Work Cloud는 특히 주의해서 확인하세요. 일부 필드는 부분적으로만 지원되거나 검증이 필요합니다. 구성 참조의 Work 호환성을 참조하세요.

사용자가 기능이나 필수 플러그인에 액세스할 수 없는 경우 워크스페이스 권한과 플러그인 제어를 별도로 확인합니다.

TOML 구성 참조

다음 예시는 requirements.toml에 동일한 정책 의도를 표현합니다. 파일이나 TOML 편집기로 정책을 관리할 때 사용하세요. Agent Security에서 제공하는 제어 기능을 사용하기 위해 로컬 파일을 편집할 필요는 없습니다.

이 브라우저 예시는 기본적으로 접근을 거부하고, https://example.com에 대한 접근을 허용하며, 해당 사이트에서 업로드와 전체 CDP 접근을 차단하고, 사이트 접근 승인의 유효 기간을 현재 턴으로 제한합니다:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

브라우저 작업에 대한 자동 검토를 비활성화하려면 browser_use.disable_auto_review = true를 설정하거나, 특정 출처에 대해서만 제한하려면 출처 정책에 auto_review = "deny"를 설정하세요.

지원 대상 Enterprise 워크스페이스에서 사이트 도구를 활성화하려면 browser_use.allow_webmcp = true를 설정하세요. 이 관리형 옵트인 설정은 데스크톱 앱의 내장 브라우저에 적용됩니다. false로 설정하거나 생략하면 일반적인 기능 가용성 검사가 유지됩니다. false는 차단을 강제하지 않습니다. 사용자 환경설정과 사이트 권한은 계속 적용됩니다.

이 네이티브 앱 예시는 macOS에서 Calculator를 허용하고, 다른 앱은 기본적으로 거부하며, 앱 승인이 세션 간에 유지되지 않도록 합니다:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Windows 정책은 computer_use.windows.aumids로 패키지 앱을 식별하거나 computer_use.windows.exes로 실행 파일을 식별할 수 있습니다. 실행 파일 규칙에는 publisher_name, product_name, access가 필수이며, binary_name은 선택 사항입니다.

지원되는 모든 필드와 값은 requirements.toml 참조를 확인하세요. 개별 사이트나 앱을 제한하는 대신 기능 자체를 비활성화하려면 기능 플래그 고정을 참조하세요.

기타 데스크톱 제어

다음 데스크톱 제어 기능은 기능 가용성, Locked Use, Appshots, 기기 원격 제어를 다룹니다. 기능 가용성과 Locked Use에는 전용 설정을 사용하고, Appshots와 기기 원격 제어는 TOML로 편집 에서 구성하세요. 데스크톱 앱 트래픽의 대상 제한은 데스크톱 앱 네트워크 대상 제어를 참조하세요.

기능 플래그 고정

Agent security에 표시되는 데스크톱 기능은 전역 > 요구 사항 > 데스크톱 기능 가용성 을 여세요. 인앱 브라우저, 브라우저 사용, 외부 브라우저 사용 또는 컴퓨터 사용 을 강제로 끄기 로 설정하여 해당 기능을 비활성화한 다음 변경 사항 저장 을 선택하세요. 전체 CDP 접근 은 사용자 옵트인 차단 을 선택하여 사용자가 활성화하지 못하도록 하세요. 기능을 허용해도 제품, 플랫폼 또는 출시 범위에 따른 가용성 제한은 무시되지 않습니다.

그 밖의 지원되는 기능 플래그에는 TOML로 편집 과 전역 requirements.toml 문서 또는 지원되는 로컬 요구 사항 소스를 사용하세요. 다음 예시에는 런타임과 데스크톱 전용 기능의 고정 설정이 모두 포함되어 있습니다:

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

런타임 기능에는 config.toml의 [features] 테이블에 있는 정식 기능 키를 사용하세요. 로컬 런타임은 인식된 기능이 이러한 고정 설정을 따르도록 정규화하고, config.toml 또는 프로필 파일의 기능 설정에 충돌하는 값을 쓰는 작업을 거부합니다.

관리형 unified_exec = false 설정은 명령 실행을 계속 허용하지만, 재개 가능한 프로세스와 write_stdin 도구를 비활성화합니다. 사용자 구성으로는 이 기능을 비활성화할 수 없습니다.

• in_app_browser = false는 내장 브라우저 창을 비활성화합니다.
• in_app_updates = false는 지원되는 환경에서 재시작 시 ChatGPT 데스크톱 앱의 자체 업데이트 기능을 비활성화합니다. 외부 패키지 배포에 영향을 주거나 이전 앱 버전에 대한 지원을 연장하지는 않습니다. 설정 및 배포 지침은 앱 업데이트 관리를 참조하세요.
• browser_use = false는 지원되는 Browser Use 기능을 비활성화합니다. 외부 Browser Use와 네이티브 앱 Computer Use에는 별도의 제어 설정이 있습니다.
• browser_use_full_cdp_access = false는 로컬 런타임에서 Browser Developer 모드를 포함한 전체 CDP 접근을 비활성화하고, ChatGPT 데스크톱 앱이 해당 설정을 활성화하지 못하도록 합니다.
• browser_use_external = false는 지원되는 브라우저 확장 프로그램을 통한 에이전트 주도 Browser Use를 비활성화합니다.
• computer_use = false는 브라우저를 네이티브 앱으로 조작하는 기능을 포함한 네이티브 앱 Computer Use와 Record & Replay 및 관련 설치 또는 설정 흐름을 비활성화합니다.

Browser Use만 비활성화해도 모든 브라우저 접근 경로가 차단되지는 않습니다. 네이티브 앱 Computer Use는 해당 기능과 앱 접근이 허용된 경우 여전히 브라우저를 조작할 수 있습니다. 이 경로에는 Browser Use의 사이트 및 기능 규칙이 적용되지 않습니다. 이를 차단하려면 컴퓨터 사용 을 강제로 끄기(computer_use = false)로 설정하거나, 다른 네이티브 앱을 계속 사용할 수 있어야 한다면 앱 규칙에서 브라우저 앱을 거부하세요. 외부 브라우저 사용 과 인앱 브라우저 는 별도로 검토하세요. 각 경로에 적용되는 제어 설정은 브라우저 세션 및 기존 로그인을 참조하세요.

이러한 키를 생략하면 정책은 일반적인 클라이언트, 플랫폼 및 출시 범위에 따른 가용성 제한 내에서 해당 기능을 허용합니다.

잠금 상태에서의 컴퓨터 사용 제한

관리형 Mac에서 사용자가 Locked Use를 활성화하지 못하도록 하려면 전역 > 요구 사항 > 데스크톱 앱 제어 를 열고, 잠금 상태에서 사용 허용 을 비활성화 로 설정한 다음 변경 사항 저장 을 선택하세요. 이 설정은 이미 Locked Use가 활성화된 Mac에서 해당 기능을 끄지는 않습니다.

TOML 편집기 또는 기기 관리 방식의 배포에서 동일한 효과를 내는 요구 사항은 다음과 같습니다:

[computer_use]
allow_locked_computer_use = false

이 요구 사항은 Locked Use를 활성화하는 제어 항목을 제거합니다. 이미 활성화된 경우에는 Locked Use를 끄지 않습니다. 생략하면 일반적인 제품 가용성과 사용자의 로컬 설정이 계속 적용됩니다.

Appshots 비활성화

Appshots를 사용하면 지원되는 클라이언트에서 애플리케이션 스냅샷을 포함할 수 있습니다. 클라우드 관리 사용자를 대상으로 이를 비활성화하려면 Agent security에서 TOML로 편집 을 열고 전역 requirements.toml의 최상위 allow_appshots 필드를 설정하세요. 기기 관리 방식의 배포에서는 해당하는 로컬 요구 사항 소스를 사용하세요:

allow_appshots = false

Appshots를 사용할 수 있는 환경에서는 allow_appshots = false가 이를 비활성화합니다. 키를 생략하면 요구 사항은 Appshots를 제한하지 않으며, 일반적인 제품 가용성 검사가 적용됩니다. 적용되는 요구 사항을 configRequirements/read를 통해 읽는 앱 서버 클라이언트에도 동일한 제한이 allowAppshots로 전달됩니다. allowAppshots 값이 생략되거나 null이면 Appshots가 비활성화되지 않습니다.

기기 원격 제어 비활성화

클라우드 관리 사용자를 대상으로 기기 원격 제어를 비활성화하려면 Agent security에서 TOML로 편집 을 사용하고 전역 requirements.toml의 최상위 allow_remote_control 필드를 설정하세요. 지원되는 로컬 요구 사항 소스에서도 allow_remote_control을 설정할 수 있습니다:

allow_remote_control = false

기기 원격 제어가 지원되는 환경에서는 allow_remote_control = false가 이를 비활성화합니다. 키를 생략하면 요구 사항은 기기 원격 제어를 제한하지 않으며, 일반적인 제품 가용성 검사가 적용됩니다. 이 요구 사항은 SSH 원격 연결을 비활성화하지 않습니다.

승인 및 실행 권한 설정

이 섹션에서 승인 동작, 권한 경계 및 초기 기본값을 설정하세요. 정책 가드레일과 기본값부터 시작하세요. 이후 작업에서는 검토자 강제 적용, 사용자 지정 권한 프로필, 파일 시스템 제한, 호스트 재정의 및 명령 규칙에 대한 TOML 요구 사항을 설명합니다.

관리자가 강제 적용하는 요구 사항(requirements.toml)

요구 사항은 보안에 민감한 설정(승인 정책, 승인 검토자, 자동 검토 정책, 샌드박스 모드, 권한 프로필, 웹 검색 모드, 관리형 훅, 사용자가 활성화할 수 있는 MCP server 및 사용할 수 있는 플러그인 마켓플레이스 소스)을 제한합니다. 구성(예: config.toml, 프로필 파일 또는 CLI 구성 재정의)을 해석할 때 값이 강제 적용된 규칙과 충돌하면 로컬 클라이언트는 호환되는 값으로 대체하고 사용자에게 알립니다. mcp_servers 허용 목록을 구성하면 클라이언트는 MCP server의 이름과 ID가 모두 승인된 항목과 일치할 때만 해당 서버를 활성화하며, 그렇지 않으면 비활성화합니다.

요구 사항은 requirements.toml의 [features] 테이블을 통해 기능 플래그도 제한할 수 있습니다. 기능이 항상 보안에 민감한 것은 아니지만, 엔터프라이즈는 원하는 경우 값을 고정할 수 있습니다. 생략한 키는 제한되지 않습니다.

Codex 0.138.0 이상에서는 allowed_permission_profiles 및 관리형 default_permissions와 함께 권한 프로필을 사용하는 것이 좋습니다. 여전히 sandbox_mode를 구성하는 레거시 배포에서만 allowed_sandbox_modes를 사용하세요.

정확한 키 목록은 구성 참조의 requirements.toml 섹션을 참조하세요.

승인, 샌드박스 및 웹 검색 가드레일 설정

요구 사항 > 정책 가드레일 을 사용하여 지원되는 클라이언트의 선택지를 제한하세요. 이러한 제어 설정은 구성을 제한하며, 초기값을 선택하지는 않습니다. 초기값은 기본값 에서 별도로 설정하세요.

1. 전역 에서 승인 정책 을 열고 허용할 승인 방식을 선택합니다. 예를 들어 필요할 때 요청 은 에이전트가 샌드박스 권한 확대 등의 작업에 대해 승인을 요청할 수 있도록 합니다. 요청 안 함 은 승인 요청을 차단하며, 무제한 실행 권한을 부여하지는 않습니다.
2. 샌드박스 모드 를 열어 기존 샌드박스 선택지를 제한합니다. 읽기 전용 은 쓰기를 제한하고, 워크스페이스 쓰기 는 워크스페이스와 구성된 쓰기 가능 루트 내에서 쓰기를 허용하며, 전체 액세스 는 파일 시스템 샌드박스 제한을 해제합니다. sandbox_mode 대신 권한 프로필을 사용하는 배포에서는 권한 프로필 요구 사항을 사용합니다.
3. 전역 에서 웹 검색 모드 를 열어 웹 검색을 제한합니다. 캐시됨 을 선택하면 실시간 검색 없이 캐시된 검색만 허용하고, 사용 안 함 을 선택하면 웹 검색을 끕니다. 웹 검색 제한은 명령의 네트워크 규칙과 별개입니다.
4. 허용된 선택지와 해당 기본값을 검토한 다음 변경 사항 저장 을 선택합니다.

요구 사항을 설정하지 않으면 해당 정책에 따른 제한이 적용되지 않습니다. 그 밖의 적용 가능한 정책은 계속 적용됩니다. 신뢰할 수 없는 명령에 대해 요청 옵션은 요구 사항 허용 목록의 untrusted에 해당하며, 더 이상 사용되지 않는 명시적 approval_policy = "untrusted" 설정을 복원하지는 않습니다. 이 경우 아래의 마이그레이션 안내를 따르세요.

웹 검색을 제한하려면 전역 > 요구 사항 > 정책 보호 장치 > 웹 검색 모드 를 사용합니다. 이에 해당하는 TOML은 다음과 같습니다.

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] 설정은 "disabled"만 허용합니다. 예를 들어 allowed_web_search_modes = ["cached"]는 danger-full-access 세션에서도 실시간 웹 검색을 차단합니다.

구성 기본값 설정

기본값은 구성원에게 초기 구성을 제공합니다. 제한을 강제하거나 워크스페이스 기능에 대한 액세스 권한을 부여하지는 않습니다.

1. 정책의 기본값 카드를 엽니다. 에이전트 전체에 적용되는 기본값은 전역 에 두고, 지원되는 실행 기본값은 사용 가능한 환경 탭에서 설정합니다.
2. 명령 실행 에서 초기 승인 정책 과 승인 검토자, 해당하는 샌드박스 모드 또는 기본 권한 을 선택합니다. 검토자는 기본적으로 승인 요청을 검토할 사람을 결정하고, 승인 정책은 요청이 발생할 수 있는 시점을 결정합니다.
3. 웹 검색 에서 초기 웹 검색 모드와 웹 검색 컨텍스트 를 선택합니다. 앱 및 도구 에서 지원되는 앱 도구에 대한 앱/커넥터, 오픈 월드 도구, 파괴적 도구 를 검토합니다.
4. 기본값이 요구 사항 을 충족하는지 확인한 다음 변경 사항 저장 을 선택합니다.

플러그인 마켓플레이스 구성처럼 시각적 컨트롤이 없는 지원 기본값에는 TOML로 편집 을 사용합니다. 이러한 클라우드 기본값에는 일반 구성 우선순위가 적용됩니다. 이는 시작 시 관리형 기본값을 로컬 구성보다 우선하는 기존 managed_config.toml 우선순위와 다릅니다.

requirements.toml 예시

다음 예시는 --ask-for-approval never 및 --sandbox danger-full-access(--yolo 포함)을 차단합니다.

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

여기서 untrusted는 다음 설정에서 파생된 더 엄격한 승인 동작을 유지합니다: trust_level = "untrusted". 그렇다고 approval_policy = "untrusted"를 명시적으로 지정하는 설정이 지원되는 것은 아닙니다.

더 이상 사용되지 않는 untrusted 승인 정책 마이그레이션

Codex와 ChatGPT Work는 더 이상 approval_policy = "untrusted"를 지원하지 않습니다. 관리형 기본값, 기존 managed_config.toml 및 이 값을 설정하는 모든 사용자, 프로젝트, 프로필 또는 시작 구성에서 제거합니다.

대화형 읽기 전용 사용에는 approval_policy = "on-request"와 함께 관리형 요구 사항에서 허용하는 읽기 전용 샌드박스 또는 권한 프로필을 선택합니다. 해당 샌드박스에서 허용하는 명령은 승인 없이 실행할 수 있습니다.

더 엄격한 명령 승인을 유지하려면 명시적 approval_policy 설정을 생략하고, 사용자 수준의 프로젝트 항목에 trust_level = "untrusted"를 설정합니다. 해당 항목은 ~/.codex/config.toml에 있으며, allowed_approval_policies에는 untrusted를 유지합니다. 이렇게 하면 프로젝트 로컬 구성도 비활성화됩니다. on-request를 명시적으로 설정하면 해당 정책보다 우선합니다. 예시와 보안상의 절충 사항은 더 이상 사용되지 않는 untrusted 승인 정책에서 마이그레이션을 참고하세요.

자동 검토 정책 구성

자동 검토를 기본값으로 설정하려면 전역 > 기본값 > 명령 실행 > 승인 검토자 를 사용합니다. 기본값을 설정해도 사용자는 허용된 다른 검토자를 선택할 수 있습니다. 자동 검토를 필수로 지정하거나 조직의 검토 지침을 제공하려면 TOML로 편집 을 사용하여 전역 requirements.toml을 편집합니다. 이러한 요구 사항은 브라우저의 자동 검토 컨트롤과 별개입니다.

자동 검토를 필수로 지정하거나 허용하려면 allowed_approvals_reviewers를 사용합니다. 자동 검토를 필수로 지정하려면 ["auto_review"]로 설정하고, 사용자가 수동 승인을 선택할 수 있게 하려면 "user"를 포함합니다.

자동 검토 정책의 테넌트별 섹션을 대체하려면 guardian_policy_config를 설정합니다. 로컬 런타임은 계속 기본 제공 검토자 템플릿과 출력 규약을 사용합니다. 관리형 guardian_policy_config는 로컬 [auto_review].policy보다 우선합니다.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

사용 가능한 권한 프로필 제어

사용자가 처음 사용할 기본 제공 프로필을 선택하려면 기본값 > 명령 실행 > 기본 권한 을 사용합니다. 사용자가 선택할 수 있는 프로필을 제한하거나 사용자 지정 프로필을 정의하려면 TOML로 편집 을 사용하고, 해당하는 전역 범위 또는 지원되는 실행 환경 범위에 requirements.toml을 구성합니다. 기본값을 선택하는 것만으로는 사용 가능한 프로필이 제한되지 않습니다.

사용자가 선택할 수 있는 기본 제공 및 사용자 지정 권한 프로필을 제어하려면 allowed_permission_profiles를 사용하세요. 이는 allowed_sandbox_modes에 대응하는 권한 프로필 설정입니다. 사용자가 권한을 선택하는 방식에 맞는 허용 목록을 사용하세요.

권한 프로필 허용 목록에는 Codex 0.138.0 이상이 필요합니다. Codex 0.137.0 및 이전 버전은 allowed_permission_profiles와 관리형 default_permissions를 무시합니다.

모든 관리형 클라이언트가 지원되는 릴리스를 실행하게 된 후에만 아래의 권한 프로필 예시를 사용하세요. 전체 클라이언트 업그레이드가 완료되기 전에는 관리형 사용자 지정 프로필을 배포하지 마세요.

이 테이블이 있으면 허용된 프로필의 전체 목록으로 간주됩니다. true로 설정된 프로필은 허용하고, 생략되거나 false로 설정된 프로필은 거부하며, 향후 Codex 버전에 추가되는 기본 제공 프로필도 마찬가지입니다.

표준 프로필 허용

다음 정책은 읽기 전용 및 워크스페이스 액세스는 허용하지만 전체 액세스는 허용하지 않습니다.

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

관리형 최소 권한 기본값 추가

관리자는 같은 요구 사항 소스에 사용자 지정 프로필을 정의할 수 있습니다. 사용자의 로드된 구성에 있는 이름과 충돌하지 않는 조직별 프로필 이름을 사용하세요. 사용자 지정 이름은 :으로 시작하거나 예약된 filesystem 이름을 사용할 수 없습니다.

Codex 0.137.0 이하를 실행하는 클라이언트에는 관리형 사용자 지정 프로필을 배포하지 마세요. 이러한 클라이언트는 프로필 테이블을 인식하지만 이를 선택하는 관리형 기본값은 인식하지 못합니다.

예시는 다음과 같습니다.

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

엔터프라이즈에서 정의한 프로필만 허용

사용자가 관리자 정의 프로필만 선택해야 한다면 모든 기본 제공 프로필을 생략하세요.

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

사용자가 기본 제공 :workspace 프로필을 직접 선택할 수 없더라도 사용자 지정 프로필은 :workspace를 확장할 수 있습니다.

다른 소스에서 허용한 프로필 끄기

권한 허용 목록은 프로필 이름별로 조합됩니다. 클라우드 요구 사항은 시스템 요구 사항보다 우선순위가 높으므로, 클라우드 요구 사항에서 false를 사용해 시스템 파일이 허용한 프로필을 끌 수 있습니다.

클라우드 요구 사항:

default_permissions = ":read-only"

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

시스템 요구 사항:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

default_permissions를 허용된 프로필로 명시적으로 설정하세요. 생략하면 :workspace와 :read-only가 모두 명시적으로 허용된 경우에만 로컬 런타임이 :workspace를 기본값으로 사용합니다. allowed_permission_profiles가 없으면 관리형 요구 사항은 사용자가 선택할 수 있는 프로필 이름을 제한하지 않습니다. 모든 항목은 기본 제공 프로필이나 로드된 구성 또는 요구 사항 소스에 정의된 사용자 지정 프로필을 지정해야 합니다. 동작을 중앙에서 제어하려면 관리형 요구 사항에 사용자 지정 프로필을 정의하세요.

읽기 거부 요구 사항 적용

TOML로 편집 을 사용하여 해당하는 전역 또는 지원되는 실행 환경의 requirements.toml에 파일 시스템 제한을 추가합니다. 이러한 제한은 민감한 경로의 읽기를 차단합니다. 읽기 전용 기본값만으로는 파일이 숨겨지지 않습니다.

관리자는 정확한 경로나 glob 패턴에 대한 읽기를 [permissions.filesystem]으로 거부할 수 있습니다. 사용자는 로컬 구성으로 이러한 요구 사항을 완화할 수 없습니다.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

읽기 거부 요구 사항이 있으면 로컬 런타임은 전체 액세스 권한을 거부하고, 이를 적용할 수 있도록 로컬 실행을 읽기 전용 또는 워크스페이스 샌드박스로 유지합니다. 네이티브 Windows에서 관리형 deny_read는 직접 파일을 다루는 도구에 적용됩니다. 셸 하위 프로세스의 읽기에는 이 샌드박스 규칙이 적용되지 않습니다.

호스트별 샌드박스 요구 사항 재정의

호스트별 요구 사항을 작성하려면 에이전트 보안에서 TOML로 편집 을 사용합니다. 환경 컨트롤은 실행 환경을 선택하고, 호스트 패턴은 지원되는 런타임 내에서 일치하는 컴퓨터를 선택합니다.

하나의 관리형 정책이 호스트마다 다른 샌드박스 요구 사항을 적용해야 한다면 [[remote_sandbox_config]]를 사용하세요. 예를 들어 노트북에는 더 엄격한 기본값을 유지하면서 일치하는 개발 장비 또는 CI 러너에는 워크스페이스 쓰기를 허용할 수 있습니다. 현재 호스트별 항목은 allowed_sandbox_modes만 재정의합니다.

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

로컬 런타임은 각 hostname_patterns 항목을 최선의 방식으로 확인한 호스트 이름과 비교합니다. 가능한 경우 정규화된 전체 도메인 이름을 우선하며, 그렇지 않으면 로컬 호스트 이름을 사용합니다. 일치는 대소문자를 구분하지 않습니다. *는 모든 문자 시퀀스와 일치하고, ?는 문자 하나와 일치합니다.

동일한 요구 사항 소스에서는 처음 일치하는 [[remote_sandbox_config]] 항목이 적용됩니다. 일치하는 항목이 없으면 로컬 런타임은 최상위 allowed_sandbox_modes를 유지합니다. 호스트 이름 일치는 정책 선택에만 사용됩니다. 이를 인증된 기기 증명으로 간주하지 마세요.

요구 사항의 명령 규칙 적용

에이전트 보안에서 TOML로 편집 을 사용하여 전역 requirements.toml에 명령 규칙과 MCP server 제한을 추가합니다. 명령 규칙은 일치하는 명령에 대한 승인 또는 거부 결정을 지정하고, MCP 제한은 클라이언트가 활성화할 수 있는 서버 ID를 제한합니다. 승인 정책 컨트롤에서는 이 두 규칙 집합을 작성할 수 없습니다.

관리자는 requirements.toml에서 제한적인 명령 규칙을 [rules] 테이블로 적용할 수도 있습니다. 이러한 규칙은 일반 .rules 파일과 병합되며, 가장 제한적인 결정이 계속 우선합니다.

.rules와 달리 요구 사항 규칙은 decision을 지정해야 하며, 해당 결정은 "prompt" 또는 "forbidden"이어야 합니다("allow"는 허용되지 않음).

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

로컬 클라이언트가 활성화할 수 있는 MCP server를 제한하려면 mcp_servers 승인 목록을 추가합니다. stdio 서버는 command를 기준으로 일치 여부를 확인하고, 스트리밍 가능한 HTTP 서버는 url을 기준으로 확인합니다.

[mcp_servers.docs]
identity = { command = "codex-mcp" }

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

문자열 형식의 identity.command는 구성된 command만 일치 여부를 확인합니다. args, cwd, env 또는 env_vars는 검사하지 않습니다.

stdio 호출 전체를 제한하려면 실행 파일과 각 위치 인수의 일치 여부를 확인합니다.

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

실행 파일, 인수 개수 및 인수 순서가 일치해야 합니다. 인수 및 URL 규칙은 exact, prefix 및 전체 값에 대한 regex 일치를 지원합니다. 구조화된 명령 규칙도 cwd, env 또는 env_vars는 검사하지 않습니다. 플러그인에 포함된 MCP server는 다음 위치에서 동일한 ID 구조를 사용합니다. plugins.<plugin>.mcp_servers.<server>.

mcp_servers가 있지만 비어 있으면 로컬 클라이언트는 모든 MCP server를 비활성화합니다.

네트워크 액세스 구성

명령 네트워킹과 데스크톱 앱 네트워킹은 서로 다른 컨트롤을 사용합니다. 지원되는 명령 트래픽에 대해 네트워크 사용 제어 부터 설정하고, 환경 및 런타임 제한을 검토한 다음, 필요하면 별도의 데스크톱 앱 요구 사항을 사용합니다. 브라우저 사이트 규칙은 계속 브라우저 및 Computer Use 제어에서 관리합니다.

네트워크 액세스 요구 사항 구성

에이전트 보안에서 지원되는 명령 네트워킹을 관리하려면 요구 사항 > 네트워크 사용 제어 를 사용합니다. 전역 에서 공통 기준을 구성하거나, 사용 가능한 로컬 환경 또는 Codex Cloud 환경 탭에서 환경별 실행 설정을 구성합니다.

1. 관리형 네트워킹 을 켜기 로 설정하여 관리형 명령 트래픽에 도메인 규칙을 적용합니다. 도메인 규칙을 추가하는 것만으로는 관리형 프록시가 활성화되지 않습니다.
2. 네트워크 규칙 에서 네트워크 규칙 추가 를 선택합니다. 도메인 에 api.openai.com 또는 **.example.com 등을 URL 스킴이나 경로 없이 입력합니다. 액세스 에서 허용 또는 거부 를 선택한 다음 규칙 저장 을 선택하여 초안을 업데이트합니다. 다른 대상에도 이 과정을 반복합니다.
3. 사용자 설정과 도메인별 승인으로 관리형 허용 목록을 확장하지 못하게 하려면 관리자가 추가한 도메인만 허용 을 켜기 로 설정합니다. 필요한 허용 항목을 포함하세요. 거부 항목만 있는 목록은 다른 대상을 허용하지 않습니다.
4. 로컬 리스너나 비공개 대상이 필요한 워크플로에서는 로컬 네트워크 액세스 허용 을 검토합니다. 직접 로컬 연결은 프록시의 도메인 규칙을 우회할 수 있습니다. 이 설정을 변경하기 전에 아래의 Codex Cloud 연결 제한을 검토하세요.
5. 상속된 규칙과 유효성 검사 메시지를 검토한 다음 변경 사항 저장 을 선택합니다. 영향을 받는 모든 실행 환경에서 성공해야 하는 요청과 차단되어야 하는 요청을 각각 테스트합니다.

관리형 네트워킹 을 끄기 로 설정하면 해당 범위에서 작성한 네트워크 규칙이 지워지고 명시적인 꺼짐 값이 저장됩니다. 인터넷 액세스가 비활성화되는 것은 아닙니다. 설정 안 함 은 해당 범위에서 작성한 네트워크 설정을 제거하여 적용 가능한 정책 또는 런타임 기본값이 적용되도록 합니다. 환경 설정을 제거하면 상속된 전역 규칙이 드러날 수 있습니다. 시각적 편집기로 표현할 수 없는 고급 네트워크 필드나 기존 레거시 도메인 목록에는 TOML로 편집 을 사용하세요.

관리자가 네트워크 액세스 요구 사항을 중앙에서 정의해야 할 때는 requirements.toml에서 [experimental_network]를 사용하세요. 이러한 요구 사항은 사용자 features.network_proxy 토글과 별개입니다. 해당 기능 플래그 없이도 샌드박스 네트워킹을 구성할 수 있지만, 활성 샌드박스에서 네트워킹이 꺼져 있으면 명령에 네트워크 액세스 권한을 부여하지 않습니다. 관리형 프록시를 활성화하려면 experimental_network.enabled = true를 설정하세요. 도메인 규칙만으로는 프록시가 활성화되지 않습니다.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

experimental_network.managed_allowed_domains_only = true는 [experimental_network.domains]에도 관리자 소유 "allow" 항목을 정의하고 해당 규칙을 배타적으로 적용하려는 경우에만 사용하세요. 관리형 허용 규칙 없이 true가면 사용자가 추가한 도메인 허용 규칙은 더 이상 유효하지 않습니다. 정식 domains 맵을 레거시 allowed_domains 또는 denied_domains 목록과 함께 사용하지 마세요.

*.example.com은 하위 도메인에만 일치합니다. **.example.com은 루트 도메인과 그 하위 도메인에 일치합니다. 일치하는 거부 규칙은 허용 규칙보다 우선합니다.

도메인 구문, 로컬/비공개 대상 규칙, 허용보다 거부가 우선하는 동작, DNS 리바인딩 제한은 에이전트 승인 및 보안에 설명된 샌드박스 네트워킹 동작과 같습니다.

프록시는 샌드박스 내부에서 실행되는 로컬 명령을 라우팅합니다. 브라우저 도구도 오리진에 접근하기 전에 관리형 네트워크 거부 규칙과 허용 목록 외 접근을 제한하는 목록을 확인합니다. 이는 별도의 정책 검사이며, 브라우저 트래픽을 명령 프록시를 통해 라우팅하는 것은 아닙니다. 웹 검색, 앱 및 커넥터, MCP server, 네이티브 앱 트래픽, Codex 서비스 요청 또는 기타 기능별 트래픽은 필터링하지 않습니다. 각 영역에 해당하는 제어를 사용하세요:

• allowed_web_search_modes를 사용하여 웹 검색을 제한하세요.
• features.apps = false를 사용하여 앱 및 커넥터 통합을 비활성화하고, features.plugins = false를 사용하여 지원되는 경우 플러그인을 비활성화하세요.
• 관리형 mcp_servers 승인 목록을 사용하여 MCP server를 제한하세요.
• browser_use, in_app_browser 및 computer_use 등의 기능 요구 사항을 사용하여 브라우저 및 컴퓨터 사용 기능을 제한하세요.
• 지원되는 관리형 Codex Cloud 명령의 경우, 에이전트 보안 요구 사항과 Cloud 환경의 인터넷 설정을 별도로 구성하세요.

명령 도메인 허용 목록은 이러한 기능별 제어 기능을 대체하지 않습니다.

지원되는 관리형 Codex Cloud 실행 경로에서는 에이전트 보안 요구 사항이 명령의 네트워크 사용을 제한합니다. Codex Cloud 환경의 인터넷 설정은 별도로 적용됩니다. 에이전트 보안에서 허용된 도메인이라도 Cloud 환경의 인터넷 설정에 있는 제한을 무효화하지 않습니다. 이러한 명령 네트워크 제어만으로는 호스팅된 웹 검색, 앱 또는 MCP가 비활성화되지 않습니다. ChatGPT Work Cloud에는 별도의 기능 권한이 있으며, 이러한 에이전트 보안 요구 사항을 상속하지 않습니다.

관리형 명령 허용 목록은 관리형 프록시를 사용하는 명령에 적용됩니다. 정책이 전체 샌드박스 권한 상승을 허용하고 이를 승인한 경우, 해당 실행은 명령 프록시를 우회할 수 있습니다. 제한적인 네트워크 권한 부여는 전체 샌드박스 권한 상승과 다릅니다. 의도한 경계에 맞게 강제 적용할 승인 및 샌드박스 요구 사항을 구성하고, 일반 명령과 권한이 상승된 명령을 모두 테스트하세요.

실제로 허용되는 대상이 없는 경우: 관리형 네트워킹 과 관리자가 추가한 도메인만 허용 이 켜져 있으면 일반 관리형 명령에는 실제로 허용되는 대상이 필요합니다. 구성되거나 상속된 허용 항목이 없으면 이러한 명령에는 허용된 대상이 없습니다. 거부 항목만 있는 정책은 나머지 인터넷 대상을 암묵적으로 허용하지 않습니다. 저장하기 전에 필요한 허용 항목을 추가하고 상속된 규칙을 확인하세요. 이 제한은 관리형 명령 프록시에 적용되며, 모든 도구나 승인된 전체 샌드박스 권한 상승에 적용되는 것은 아닙니다.

Codex Cloud 로컬/프라이빗 연결: 로컬/프라이빗 연결을 명시적으로 Off로 설정하면 대상 도메인이 허용되어 있어도 Codex Cloud가 업스트림 프록시에 연결하지 못할 수 있습니다. 최종 allow_local_binding 값을 확인하고 어떤 정책이나 설정에서 이 값을 제공하는지 파악하세요. 지원되는 Cloud 프록시 경로에서는 적용되는 요구 사항, 선택된 네트워크 프로필, 프록시 기능 설정 중 어느 것도 값을 제공하지 않을 때만 기본값이 true가 됩니다. 상속된 false도 명시적 설정으로 간주됩니다. 지원되는 경우 우선순위가 더 높은 Cloud 재정의를 설정하면 Local에서 사용하는 Global 값을 변경하지 않고도 Codex Cloud에 적용되는 이 값을 변경할 수 있습니다. 이 설정은 도메인 Allow 항목을 추가하지 않습니다. 재정의에 의존하기 전에 실행기가 이를 지원하는지 확인하세요. 이 Cloud 기본값을 Local에 적용하지 마세요.

환경 요구 사항이 비어 있으면 전역 요구 사항이 적용됩니다. 관리형 네트워킹 을 끄기 로 설정하는 것은 Cloud 환경의 인터넷 액세스 설정과 별개입니다. 실행 범위에 대한 자세한 내용은 에이전트 보안 실행 제어를 참고하세요.

네트워크 정책 우선순위와 런타임 제한

특정 정책 내에서 우선순위는 높은 순서부터 OS별 환경 재정의 → 모든 OS에 대한 환경 재정의 → 전역입니다. 우선순위가 낮은 정책이 더 구체적이더라도 우선순위가 높은 정책이 우선합니다. 일부 요구 사항에는 필드별 병합 규칙이 있습니다. 그런 다음 런타임이 최종 결정된 요구 사항을 적용합니다. 아래의 필드별 네트워크 사례는 정책 우선순위와 별도로 검토하세요.

다음 예시는 관리형 네트워킹이 이미 구성되어 있고 우선순위가 더 높은 정책이 값을 변경하지 않는 상황에서, 동일한 정책 내의 환경 설정과 전역 설정을 비교합니다. 필드별 병합 및 런타임 동작을 설명합니다.

환경별로 서로 다른 도메인 액세스 설정

정책 내의 동일한 도메인 규칙에 대해 관리자는 환경 재정의로 전역에서 거부한 도메인을 허용하거나 전역에서 허용한 도메인을 거부할 수 있습니다. 환경 재정의가 없으면 전역 규칙이 상속됩니다. 실제로 적용되는 다른 거부 규칙이나 액세스 제어가 여전히 요청을 차단할 수 있습니다.

도메인 규칙의 결합 방식

이 결과는 우선순위가 더 높은 정책이 결과를 변경하지 않는 상황에서, 하나의 정책 내에 있는 동일한 도메인 키를 비교한 것입니다. 우선순위가 더 높은 값이 동일한 키의 값을 대체합니다. 상속된 다른 키는 유지됩니다. 허용 규칙은 상속된 와일드카드처럼 일치하는 다른 거부 규칙을 우회하지 않습니다. 비어 있는 환경 맵은 상속된 규칙을 지우지 않습니다.

예시: 전역에서 packages.example.com을 거부하고 개발 환경에서 허용합니다. 개발 환경에서는 위 조건에 따라 이를 허용할 수 있습니다. 프로덕션 환경은 재정의하지 않는 한 전역 거부 규칙을 상속합니다.

배포된 실행기가 이러한 병합 규칙을 지원하는지 확인하세요. 일반 관리형 실행기의 지원 범위는 아직 검증이 필요합니다.

Orchestrator 제한. 클라우드 런타임은 관리형 HTTP/SOCKS 리스너 포트와 비루프백 프록시 리스너를 지원하지 않습니다. 소켓 규칙 지원 여부는 실행 경로에 따라 다릅니다. 아래 표의 로컬 실행 설정은 지원되는 Orchestrator 구성이 아닙니다.

기타 네트워크 런타임 제한

아래의 모든 필드 이름은 experimental_network 아래에 있으며, 이는 requirements.toml에 있습니다. 화살표는 동일한 정책 내의 전역 값에서 환경 값으로의 변화를 나타냅니다. 이러한 로컬 실행 사례가 동일한 설정에 대한 Orchestrator 지원을 입증하는 것은 아닙니다.

프록시 활성화, 허용 대상 제한, 업스트림 프록시 동작, Unix 소켓 규칙은 실행기별로 다르게 동작합니다. 도메인 키 결합 방식을 이러한 설정에 일반화하지 마세요. 실제 적용 값을 확인하고 배포된 런타임을 테스트하세요. Codex Cloud의 로컬/비공개 연결에 대해서는 네트워크 액세스 요구 사항 구성을 참고하세요.

배포 전 동작 확인

워크플로에서 사용하는 실제 대상, 로컬 리스너, 프록시 동작, 소켓 경로를 테스트하세요. 영향을 받는 각 환경에서 성공해야 하는 작업과 차단되어야 하는 작업을 각각 확인하세요. 배포된 런타임 버전이 사용하는 각 설정을 지원하는지 확인하세요.

데스크톱 앱의 네트워크 대상 제어

에이전트 보안의 TOML로 편집 을 사용하여 이러한 데스크톱 전용 요구 사항을 전역에 구성합니다. 네트워크 사용 제어 UI는 명령 네트워킹을 관리하며, 이는 별도의 정책입니다.

[application.network] 설정을 requirements.toml에 지정하여 데스크톱 앱의 네트워크 대상을 제한합니다. enabled = true로 설정하면 외부 요청은 HTTPS 또는 WSS를 사용해야 하며, 값이 "allow"인 도메인과 정확히 일치해야 합니다. 도메인은 [application.network.domains]에 지정합니다. 하위 도메인은 자동으로 허용되지 않습니다. 도메인 맵이 비어 있으면 어떤 외부 대상도 허용되지 않습니다. 지원되는 키는 구성 참조를 확인하세요.

이 정책은 명령의 네트워크 사용 및 브라우저 출처 규칙과 별개입니다. 네이티브 모듈이나 생성된 프로세스에는 대상 제한을 적용하지 않으며, Work Cloud 실행에도 적용되지 않습니다.

플러그인 및 관리형 훅 구성

이러한 작업에는 에이전트 보안의 TOML로 편집 또는 지원되는 로컬 구성 소스를 사용하세요. 마켓플레이스 기본값, 강제 적용되는 플러그인 제한, 관리형 훅은 용도가 서로 다릅니다. 필요한 정책에 맞는 작업을 선택하세요.

플러그인 마켓플레이스 및 기본값 구성

에이전트 보안 > TOML로 편집 을 사용하여 로컬 또는 Git 마켓플레이스와 플러그인 기본값을 전역 config.toml 문서에 정의합니다. 이러한 설정은 시스템 config.toml로 배포할 수도 있습니다. 이는 초기 마켓플레이스 및 플러그인 구성을 제공하며, 강제 적용되는 정책은 아닙니다. 구성원이 사용할 수 있는 소스를 제한하려면 마켓플레이스 소스 요구 사항을 구성하세요.

구성 키는 구성 참조를, 재정의는 구성 우선순위를, 프로젝트 수준 구성은 저장소 플러그인 설정을 참고하세요. 워크스페이스 GitHub 가져오기 및 동기화는 별개입니다.

플러그인 가용성 제어

에이전트 보안의 TOML로 편집 을 사용하여 전역 requirements.toml에 강제 적용할 플러그인 기능 설정을 구성하거나, 기기 관리 클라이언트에 로컬 요구 사항을 통해 배포합니다. 기본값 > 앱 및 도구 > 앱/커넥터 는 앱 도구 기본값을 설정하며, 강제 적용되는 features.plugins 스위치가 아닙니다. 워크스페이스 플러그인 권한은 앱 및 커넥터를 참고하세요.

지원되는 로컬 클라이언트에서 플러그인을 끄려면 requirements.toml에서 features.plugins를 false로 설정하세요.

features.plugins = false

이 설정은 사용자가 API key로 Codex에 로그인할 때도 적용됩니다. 지원되는 구성은 features.plugins 참조를 확인하세요.

플러그인 마켓플레이스 소스 제한

TOML로 편집 을 사용하여 Global requirements.toml에서 마켓플레이스 소스 요구 사항을 구성하거나 로컬 요구 사항을 통해 배포하세요. 이 규칙은 사용자가 추가하고 사용할 수 있는 로컬 또는 Git 소스를 제한합니다. 이 규칙은 마켓플레이스 기본값과 별개입니다.

플러그인 마켓플레이스 소스를 제한하려면 restrict_to_allowed_sources = true를 설정하고 하나 이상의 소스 규칙을 정의하세요:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Git 규칙은 정규화된 저장소 URL 및, 있는 경우 정확한 ref와 일치합니다. 호스트 패턴은 소문자로 변환된 Git 호스트와 비교되는 정규식입니다. 전체 호스트 일치에는 ^ 및 $를 사용하세요. 로컬 규칙에는 절대 정규화 경로가 필요합니다. 전체 스키마 및 병합 동작은 requirements.toml 참조를 확인하세요.

이 요구 사항은 규칙과 일치하지 않는 마켓플레이스 추가, 플러그인 설치 및 설정된 Git 마켓플레이스 새로 고침 작업을 거부합니다. 또한 런타임에 설정된 마켓플레이스와 해당 플러그인을 필터링합니다.

API key 카탈로그를 포함해 OpenAI가 큐레이션한 Git 마켓플레이스도 소스 허용 목록과 일치해야 합니다. 이를 허용하려면 다음 Git 소스를 ref 제약 조건 없이 포함하세요:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

큐레이션된 카탈로그를 제외하려면 해당 소스를 생략하고 더 넓은 범위의 호스트 규칙에서도 허용하지 않는지 확인하세요. 번들로 제공되는 플러그인과 원격으로 설치된 워크스페이스 플러그인은 이 큐레이션된 Git 소스 정책과 별개입니다.

이러한 소스 제한은 로컬 클라이언트가 플러그인 마켓플레이스 작업을 지원하는 경우에만 적용됩니다. 즉, 데스크톱 앱의 ChatGPT와 Codex 및 Codex CLI에 적용됩니다. 웹 또는 모바일의 ChatGPT에서 플러그인 사용을 제어하지 않으며 IDE 확장 프로그램에 플러그인을 추가하지도 않습니다.

요구 사항을 통한 관리형 훅 적용

관리형 훅은 지원되는 작업 또는 도구 이벤트에서 관리자가 정의한 동작을 실행합니다. Agent Security에서 TOML로 편집 을 사용하여 Global requirements.toml에 구성하세요. 설정 컨트롤에는 전용 훅 편집기가 없습니다. 아래 실행 경로에 따라 실행할 수 있는 훅 유형이 결정됩니다.

관리형 정책과 원격 훅이 활성화되면 로컬 액세스가 있는 Work Cloud와 dots는 클라우드 오케스트레이터에서 관리자가 관리하는 원격 MCP 훅을 사용합니다. Global requirements.toml에 mcp_tool 핸들러를 구성하세요. 로컬 액세스가 없는 Work Cloud와 개인 계정은 이러한 엔터프라이즈 훅을 사용하지 않습니다. 명령/셸, 프롬프트, 에이전트 핸들러, 로컬 구성·플러그인·로컬 디렉터리의 훅, 환경 범위 훅, SessionEnd MCP 훅은 도구가 로컬에서 실행되더라도 클라우드 오케스트레이션에서 지원되지 않습니다. 오케스트레이션과 실행이 모두 로컬에서 이루어지는 경우 기존에 지원되는 훅은 로컬 전용 Work 및 Codex 스레드에서 계속 작동합니다. 관리자는 이러한 워크플로를 위해 Agent Security에서 지원되는 관리형 훅을 계속 구성할 수 있습니다.

이러한 훅에 의존하기 전에 콜백 연결, 필요한 이벤트, 실패 시 동작을 테스트하세요. 지원되는 명시적 거부는 동작을 차단할 수 있지만, PreToolUse 콜백 오류, 시간 초과 또는 잘못된 형식의 응답은 도구를 차단하지 않은 채 훅을 실패하게 할 수 있습니다. MCP 훅은 완전한 Compliance API 감사 추적을 제공하지 않습니다. 다음 스크립트 및 디렉터리 예시는 여전히 Codex 범위에 적용됩니다.

관리자는 requirements.toml에서 직접 관리형 수명 주기 훅을 정의할 수도 있습니다. 훅 구성 자체에는 [hooks]를 사용하고, managed_dir 필드는 MDM 또는 엔드포인트 관리 도구가 참조된 스크립트를 설치하는 디렉터리를 가리키도록 설정하세요.

로컬에서 훅을 끈 사용자에게도 관리형 훅을 적용하려면 [hooks]와 함께 [features].hooks = true를 고정하세요. 관리형 훅은 허용하면서 사용자, 프로젝트, 세션, 플러그인 훅을 건너뛰려면 allow_managed_hooks_only = true를 설정하세요.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

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

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

참고:

• 로컬 런타임은 requirements.toml의 훅 구성을 적용하지만, managed_dir의 스크립트를 배포하지는 않습니다.
• MDM 또는 기기 관리 솔루션으로 해당 스크립트를 배포하세요.
• 관리형 훅 명령은 구성된 관리형 디렉터리 아래에 있는 스크립트의 절대 경로를 참조해야 합니다.
• allow_managed_hooks_only = true는 사용자, 프로젝트, 세션, 플러그인 소스의 훅을 건너뛰지만, requirements.toml 및 다른 관리형 구성 계층의 훅은 계속 로드합니다.

정책 범위와 우선순위 이해하기

이 섹션에서 정책이 적용되는 위치, 요구 사항이 결합되는 방식, 클라이언트가 클라우드 관리형 설정을 수신하는 방식, 결과를 확인하는 방법을 살펴보세요.

로컬 액세스가 있는 Work와 dots에서는 관리형 정책이 활성화되면 지원되는 Global 정책이 공유 클라우드 오케스트레이터를 제어하고, 해당 로컬 실행 요구 사항이 연결된 컴퓨터를 제어합니다. Work 클라우드 컨테이너는 기존 Work Cloud 정책을 유지하며, 지원되는 기기 제어는 로컬 실행에 계속 적용됩니다. Codex는 기존 구성 동작을 유지합니다. 관리형 구성은 워크스페이스 시트나 기능 액세스 권한을 부여하지 않습니다. 이러한 제어는 역할 및 워크스페이스 권한을 참고하세요.

Agent Security 및 Work Cloud의 로컬 컴퓨터 액세스

Admin Console의 Agent Security를 사용하여 정책과 구성을 관리하세요. 이 기능은 정책 및 구성을 대체합니다. Agent Security는 Work Cloud의 로컬 컴퓨터 액세스와 별개로 Admin Console에서 사용할 수 있습니다. 기존 정책, 할당, 순서는 유지됩니다. Agent Security에서 기존 정책을 검토하세요. Work Cloud의 로컬 컴퓨터 액세스는 별도로 활성화해야 합니다. 마이그레이션 지침은 Agent Security를 참고하세요.

정책 자동화를 Agent Security 로 이전하기 전에 다음을 수행하세요:

1. 영향을 받는 연동을 파악하세요. 정책을 업데이트하는 Terraform 구성과 스크립트 목록을 작성하고, 각각이 관리하는 정책을 기록하세요.

2. 정책 API를 사용하여 Global 설정을 관리하세요. Local 또는 Codex Cloud 설정을 관리하려면 Agent Security UI를 사용하세요. 기존 Global API 워크플로는 마이그레이션 후에도 계속 사용할 수 있습니다. 스크립트와 Terraform 연동을 테스트하고 정책 할당과 순서가 변경되지 않았는지 확인하세요.

3. 필요한 변경을 수행하고 자동화를 테스트하세요. 의도한 업데이트가 올바른 Agent Security 정책에 전달되고 그에 따른 제어가 적용되는지 확인하세요.

정책 마이그레이션은 Work 또는 dots에 로컬 컴퓨터 액세스 권한을 부여하지 않습니다. 출시 전에 정책을 검토하거나 생성하는 것이 권장되지만, 액세스 활성화를 위한 확인 절차에서 정책 생성이 필수는 아닙니다. 로컬 컴퓨터 액세스 허용 을 활성화하기 전에 마이그레이션된 기준 정책을 검토하거나, 현재 정책이 MDM을 통해서만 배포되는 경우 클라우드 기준 정책을 생성하세요. 클라우드 정책 중 하나라도 enforce_residency가 활성화되어 있으면 Work와 dots 모두에서 로컬 컴퓨터 액세스 허용 이 비활성화됩니다. 이 보호 조치는 워크스페이스 데이터 레지던시를 구성하지 않으며, 그 자체로 Work Cloud나 dots를 비활성화하지도 않습니다.

환경 재정의는 정책 내에서 지원되는 설정을 환경별로 다르게 지정합니다. 특정 정책 내에서는 우선순위가 높은 순서대로 OS별 환경 재정의 → 모든 OS 환경 재정의 → Global입니다. 우선순위가 낮은 정책이 더 구체적이더라도 우선순위가 높은 정책이 항상 우선합니다. 일부 요구 사항에는 필드별 병합 규칙이 있습니다. 워크스페이스에서 사용할 수 있는 재정의 편집기와 필드를 확인하세요.

관리형 정책과 원격 훅이 활성화되면 로컬 액세스가 있는 Work Cloud와 dots는 클라우드 오케스트레이터에서 관리자가 관리하는 원격 MCP 훅을 사용합니다. Global requirements.toml에 mcp_tool 핸들러를 구성하세요. 로컬 액세스가 없는 Work Cloud와 개인 계정은 이러한 엔터프라이즈 훅을 사용하지 않습니다. 명령/셸, 프롬프트, 에이전트 핸들러, 로컬 구성·플러그인·로컬 디렉터리의 훅, 환경 범위 훅, SessionEnd MCP 훅은 도구가 로컬에서 실행되더라도 클라우드 오케스트레이션에서 지원되지 않습니다. 오케스트레이션과 실행이 모두 로컬에서 이루어지는 경우 기존에 지원되는 훅은 로컬 전용 Work 및 Codex 스레드에서 계속 작동합니다. 관리자는 이러한 워크플로를 위해 Agent Security에서 지원되는 관리형 훅을 계속 구성할 수 있습니다. 이러한 훅에 의존하기 전에 콜백 연결, 필요한 이벤트, 실패 시 동작을 테스트하세요. 지원되는 명시적 거부는 동작을 차단할 수 있지만, PreToolUse 콜백 오류, 시간 초과 또는 잘못된 형식의 응답은 도구를 차단하지 않은 채 훅을 실패하게 할 수 있습니다. MCP 훅은 완전한 Compliance API 감사 추적을 제공하지 않습니다. 구성 참조를 참고하세요.

위치 및 우선순위

로컬 실행에서는 다음과 같이 우선순위가 낮은 것부터 높은 것 순으로 요구 사항이 적용됩니다. 이 순서는 Work Cloud의 로컬 컴퓨터 액세스에서 수행되는 로컬 단계에도 적용됩니다:

1. 시스템 requirements.toml(Linux 및 macOS를 포함한 Unix 시스템에서는 /etc/codex/requirements.toml, Windows에서는 %ProgramData%\OpenAI\Codex\requirements.toml 사용).
2. 클라우드 구성 번들로 배포되는 Agent Security 요구 사항.
3. 로컬 클라이언트가 요구 사항으로 재해석하는 기존 managed_config.toml 필드.
4. 다음을 통해 배포되는 macOS 관리형 환경설정(MDM): com.openai.codex:requirements_toml_base64.

우선순위가 높은 계층은 낮은 계층의 일반 스칼라 값과 목록 값을 재정의합니다. 테이블은 키별로 병합되지만, 규칙, 훅, 파일 시스템 제한 같은 요구 사항은 필드별 결합 방식을 따릅니다. 모든 필드가 동일한 방식으로 병합된다고 가정하지 말고, requirements.toml 참조에서 현재 스키마를 확인하세요.

이전 버전과의 호환성을 위해 지원되는 로컬 클라이언트는 기존 approval_policy, approvals_reviewer, sandbox_mode 필드를 요구 사항으로 재해석합니다. 이 변환은 필요한 경우 호환성 옵션을 추가합니다. 명시적인 허용 목록에는 requirements.toml을 사용하세요.

Work Cloud의 로컬 컴퓨터 액세스 우선순위

로컬 액세스가 있는 Work와 dots에서는 Global 오케스트레이터 정책과 실행 정책을 구분하세요. 해당 로컬 요구 사항이 연결된 컴퓨터를 제어합니다. Work 클라우드 컨테이너와 dots 클라우드 컴퓨터는 다른 실행기가 사용하는 관리형 환경 번들 대신 자체 실행 구성과 요구 사항을 사용합니다.

로컬 실행에서는 MDM 및 레거시 관리형 기기 요구 사항이 Agent Security보다 우선합니다. 기기의 시스템 요구 사항 파일은 Agent Security보다 우선순위가 낮습니다. 각 정책 내에서는 OS별 환경 재정의를 먼저 적용하고, 모든 OS에 대한 환경 재정의, Global 순으로 적용합니다. 서로 다른 정책 간에는 구체성보다 정책 우선순위가 우선합니다.

요구 사항은 제약을 부과하고, 구성 기본값은 시작 값을 제공합니다. 로컬 액세스를 사용하는 Work 및 dots에서는 관리형 정책이 활성화된 경우 지원되는 Global 정책이 공유 클라우드 오케스트레이터를 통해 적용됩니다. 연결된 컴퓨터에서의 실행에는 해당 로컬 requirements.toml 요구 사항이 적용됩니다. Work 클라우드 컨테이너와 dots 클라우드 컴퓨터는 다른 실행기 유형에서 사용하는 관리형 환경 번들 대신 자체 실행 구성과 요구 사항을 사용합니다. 로컬 실행 제한은 이러한 클라우드 컴퓨터에 자동으로 적용되지 않습니다. 클라우드 기능 권한을 검토하고 로컬 실행과 클라우드 실행을 별도로 테스트하세요.

승인 및 웹 검색을 포함한 오케스트레이터 제어 항목은 Global에 유지하세요. 제공되는 경우 전용 허용된 승인 정책 및 허용된 웹 검색 모드 제어 항목을 사용하고, 그 밖의 지원되는 필드에는 TOML을 사용하세요. 필드 목록과 실행 범위는 구성 참조를 확인하세요.

클라우드 관리형 요구 사항

사용자가 지원되는 요금제에서 ChatGPT로 로그인하면 지원되는 로컬 클라이언트는 워크스페이스와 연결된 관리자 강제 적용 요구 사항을 받을 수 있습니다. 이는 requirements.toml 호환 정책을 전달하는 채널입니다. 이 채널은 워크스페이스 액세스 권한을 부여하거나 워크스페이스 RBAC를 대체하지 않습니다. 인증 요구 사항은 로컬에서 관리해야 합니다.

에이전트 보안 제어 항목으로 공통 요구 사항을 구성하세요. 요청 시 승인과 읽기 전용 또는 워크스페이스 쓰기 샌드박스만 허용하는 정책에는 정책 가드레일 아래의 승인 정책 및 샌드박스 모드 를 사용하세요. 지원되는 셸 진입점이 실행되기 전에도 확인 메시지를 표시하려면 TOML로 편집 을 사용하여 [rules] 테이블을 Global requirements.toml에 추가하세요.

이에 해당하는 전체 TOML은 다음과 같습니다.

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

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

관리되는 모든 클라이언트 버전이 선택한 키를 지원하는지 확인하세요. 대상 사용자 또는 그룹에 정책을 할당하고 지원되는 클라이언트에서 정책이 적용되는지 확인하세요. 최신 스키마는 구성 참조를 확인하고, 현재 할당 동작은 관리 화면을 확인하세요.

서비스는 로그인한 ID에 적용되는 엔터프라이즈 관리형 요구 사항 계층을 선택합니다. 로컬 클라이언트는 이러한 계층을 위치 및 우선순위에 설명된 다른 요구 사항 소스와 함께 평가합니다. 워크스페이스 측 생성 및 할당에는 현재 관리 화면을 사용하세요. 복사한 그룹 매칭 알고리즘에 의존하지 마세요. 이 동작은 관리 서비스에서 담당하며, 로컬 요구 사항 형식과 무관하게 변경될 수 있습니다.

지원되는 키와 예시는 requirements.toml 예시 및 requirements.toml 참조를 확인하세요.

로컬 클라이언트가 클라우드 관리형 요구 사항을 적용하는 방식

아래의 로컬 로딩 및 캐시 동작은 지원되는 로컬 클라이언트에 대한 설명입니다. Work Cloud를 통한 로컬 컴퓨터 액세스를 사용하는 이미 실행 중인 작업에 변경된 클라우드 정책이 언제 적용되는지를 규정하지는 않습니다. 변경된 제한에 의존하기 전에 실제 적용된 정책을 확인하세요.

사용자가 지원되는 로컬 클라이언트를 시작하고 지원되는 요금제에서 ChatGPT로 로그인하면, 클라이언트는 먼저 ID가 일치하는 유효한 캐시 항목이 있는지 확인합니다. 유효한 항목이 없으면 클라이언트는 재시도를 통해 해당 번들을 가져오고 성공 시 서명된 캐시 항목을 기록합니다. 요청이 실패하거나 시간이 초과되고 사용 가능한 유효한 캐시가 없으면 클라우드 구성 번들 로딩은 클라우드 관리형 요구 사항 계층 없이 조용히 시작하는 대신 오류를 반환합니다.

캐시 처리가 끝나면 클라이언트는 클라우드 요구 사항을 위에서 설명한 다른 요구 사항 계층과 결합합니다. 백그라운드 새로 고침은 캐시된 번들을 업데이트하여 이후 구성 로딩에서 사용할 수 있도록 합니다. 이 동작이 이미 실행 중인 작업에서 변경된 정책을 즉시 사용한다는 것을 보장하지는 않습니다. 일부 데스크톱 설정에는 앱 재시작이 필요합니다. 재시작 안내가 표시되면 따르고, 변경 사항에 의존하기 전에 실제 적용된 설정을 확인하세요.

관리자 및 직원 경험 확인

각 관리형 정책의 담당자를 지정하고, 정책을 받아야 하는 사용자 또는 그룹을 기록하며, 파일 시스템, 네트워크, 승인 또는 권한 프로필 제한을 두는 업무상 이유를 문서화하세요.

의도한 권한을 가진 사용자와 함께 허용되는 워크플로와 차단되는 워크플로를 테스트하세요. 지원되는 클라이언트에서 실제 적용된 설정을 확인하세요. 워크스페이스 역할이나 그룹만으로는 로컬 런타임 제한이 강제 적용되지 않습니다.

에이전트 보안의 정책 테스트 를 사용하여 선택한 구성원, 그룹 또는 역할과 일치하는 정책을 확인하세요. 편집 가능한 세션에서는 현재 초안을 저장하지 않고 검사합니다. 결과에는 선택된 정책이 표시되며, 최종 병합된 구성이나 클라이언트가 제한을 강제 적용하는지는 표시되지 않습니다. 저장 후에는 관련된 각 클라이언트와 실행 경로에서 허용되는 워크플로와 차단되는 워크플로를 테스트하세요.

기기 관리형 구성 배포

인증 제한 및 기기 관리형 정책에는 로컬 시스템 요구 사항 또는 MDM을 사용하세요. 레거시 managed_config.toml 메커니즘은 에이전트 보안의 기본값 과 시작 시 우선순위가 다릅니다. MDM 워크플로는 요구 사항과 레거시 기본값을 모두 다룹니다.

로컬에서 인증 관리

allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store 및 chatgpt_base_url을 로컬 시스템의 requirements.toml 또는 macOS MDM 요구 사항에 설정하세요. Codex는 이 네 필드를 클라우드 관리형 요구 사항에서 무시합니다. 로컬 인증 요구 사항은 자격 증명을 로드하기 전과 Codex가 클라우드 정책을 가져오기 전에 적용됩니다.

승인된 워크스페이스에 ChatGPT로 로그인하도록 요구하고 자격 증명을 OS 자격 증명 저장소에 저장하려면 다음을 사용하세요.

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

allowed_login_methods에는 chatgpt, api 또는 둘 다 지정할 수 있습니다. 생략하면 이 설정은 로그인 방법을 제한하지 않습니다. 설정하는 경우 목록에 하나 이상의 방법이 포함되어야 합니다. api는 Amazon Bedrock을 포함한 API 인증을 허용합니다. 워크스페이스 제한은 Codex 액세스 토큰에도 적용됩니다.

사용자가 구성한 forced_login_method 및 forced_chatgpt_workspace_id는 요구 사항을 따라야 합니다. 사용자가 선택하는 워크스페이스는 관리형 워크스페이스 허용 목록에도 포함되어 있어야 합니다. 일치하는 워크스페이스가 없으면 ChatGPT 로그인을 사용할 수 없습니다. 허용된 경우 API 인증은 계속 사용할 수 있습니다. 사용 가능한 로그인 방법이 없으면 Codex는 시작을 거부합니다.

자격 증명 저장 모드와 서비스 URL 구성은 요구 사항 참조를 확인하세요.

관리형 기본값 (managed_config.toml)

지원되는 클라우드 관리형 시작 값에는 에이전트 보안 기본값을 사용하세요. 이 섹션에서는 레거시 기기 관리형 managed_config.toml 메커니즘과 그에 따른 다른 시작 시 우선순위를 다룹니다. 에이전트 보안에서 기본값 을 편집해도 managed_config.toml 파일이 구성원의 기기에 배포되지는 않습니다.

관리형 기본값은 지원되는 로컬 클라이언트가 시작할 구성을 설정합니다. 시작할 때 사용자의 로컬 config.toml 및 모든 CLI --config 재정의를 덮어씁니다. 사용자는 현재 실행 중에도 해당 설정을 변경할 수 있으며, 다음에 클라이언트를 시작하면 기본값이 다시 적용됩니다.

GPT-5.5는 2026년 10월 14일 정오(PDT 기준, UTC 19:00)에 ChatGPT 로그인을 사용하는 Codex에서 지원 종료됩니다. 관리형 기본값, macOS MDM 프로필 또는 저장된 구성에서 해당 사용자의 gpt-5.5를 고정한 경우 사용 가능한 모델로 교체하세요. 관리자가 영향을 받는 사용자에게 활성화한 후에는 gpt-6.1-sol을 선택하세요. OpenAI API와 API key로 인증된 Codex 세션은 영향을 받지 않습니다. 워크스페이스 모델 가용성을 참조하세요.

여전히 gpt-5.4 또는 gpt-5.4-mini를 고정하는 구성은 GPT-5.4 마이그레이션 지침을 따르세요.

관리형 기본값이 요구 사항을 충족하는지 확인하세요. 로컬 런타임은 허용되지 않는 값을 거부합니다.

우선순위 및 계층 구성

로컬 런타임은 다음 순서로 유효 구성을 조합합니다(위 항목이 아래 항목을 재정의함).

• 관리형 환경설정(macOS MDM, 가장 높은 우선순위)
• managed_config.toml(시스템/관리형 파일)
• config.toml(사용자의 기본 구성)

CLI --config key=value 재정의는 기본 구성에 적용되지만 관리형 계층이 이를 재정의합니다. 즉, 로컬 플래그를 제공하더라도 매 실행은 관리형 기본값에서 시작합니다.

클라우드 config.toml은 일반 설정 우선순위를 사용하며, 위의 레거시 순서를 따르지 않습니다. 클라우드 requirements.toml은 요구 사항 우선순위를 사용합니다.

위치

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/non-Unix: ~/.codex/managed_config.toml

파일이 없으면 로컬 런타임은 관리형 계층을 건너뜁니다.

managed_config.toml 예시

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

권장 보호 장치

• 대부분의 사용자에게는 승인을 사용하는 workspace-write를 권장하며, 전체 액세스는 통제된 컨테이너에만 허용하세요.
• 보안 검토에서 수집기 또는 워크플로에 필요한 도메인을 허용하지 않는 한 network_access = false를 유지하세요.
• 관리형 구성으로 OTel 설정(exporter, environment)을 고정하되, 정책에서 프롬프트 내용 저장을 명시적으로 허용하지 않는 한 log_user_prompt = false를 유지하세요.
• 로컬 config.toml과 관리형 정책 간의 차이를 정기적으로 감사하여 설정 이탈을 감지하세요. 관리형 계층은 로컬 플래그와 파일보다 우선해야 합니다.

macOS 관리형 환경설정(MDM)

macOS에서 관리자는 다음 위치에 base64로 인코딩된 TOML 페이로드를 제공하는 기기 프로필을 푸시할 수 있습니다.

• 환경설정 도메인: com.openai.codex
• 키:
  • config_toml_base64(관리형 기본값)
  • requirements_toml_base64(요구 사항)

로컬 런타임은 이러한 "관리형 환경설정" 페이로드를 TOML로 파싱합니다. 관리형 기본값(config_toml_base64)의 경우 관리형 환경설정이 가장 높은 우선순위를 갖습니다. 요구사항(requirements_toml_base64)의 경우 우선순위는 요구사항 순서를 따릅니다. 동일한 요구사항 측 [features] 테이블은 requirements_toml_base64에서도 작동합니다. 여기에서도 정식 기능 키를 사용하세요.

MDM 설정 워크플로

로컬 런타임은 표준 macOS MDM 페이로드를 지원하므로 Jamf Pro, Fleet 또는 Kandji 같은 도구로 설정을 배포할 수 있습니다. 간단한 배포 절차는 다음과 같습니다.

1. 관리형 페이로드 TOML을 만들고 base64로 인코딩합니다(줄 바꿈 없음).
2. 문자열을 MDM 프로필의 com.openai.codex 도메인 아래 config_toml_base64(관리형 기본값) 또는 requirements_toml_base64(요구 사항)에 넣습니다.
3. 프로필을 푸시한 다음 사용자에게 지원되는 로컬 클라이언트를 다시 시작하고 시작 구성 요약에 관리형 값이 반영되는지 확인하도록 요청합니다.
4. 정책을 취소하거나 변경할 때 관리형 페이로드를 업데이트합니다. 클라이언트는 다음에 실행될 때 새로 고친 환경설정을 읽습니다.

페이로드에 비밀 정보나 변경이 잦은 동적 값을 포함하지 마세요. 관리형 TOML을 변경 관리 대상인 다른 MDM 설정과 동일하게 취급하세요.