Codex güvenlik uygulama rehberi

Çalışanların Codex'te şirketinizin ChatGPT çalışma alanı üzerinden oturum açması gerektiğinde ve yönetilen uç noktalarda kişisel ChatGPT hesapları ile API key kullanarak kimlik doğrulama yasaklandığında bu tarifi kullanın.

Amaçlanan sonuç

Şirket tarafından yönetilen cihazlarda Codex, yalnızca şirketin ChatGPT çalışma alanında ChatGPT ile oturum açılmasını kabul eder.

Ön koşullar

• Onaylı ChatGPT Enterprise çalışma alanının UUID'si.

• Codex yönetilen yapılandırmasını uç noktalara dağıtmanın bir yolu.

• Yönetilen uç noktalarda API key kullanarak kimlik doğrulamayı yasaklama kararı.

Yapılandırın

1. Onaylı çalışma alanının UUID'sini kurum içi yapılandırma deponuza kaydedin.

2. Yerel requirements.toml dosyasına zorunlu kimlik doğrulama gereksinimleri ekleyin:

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

İlk anahtar yalnızca ChatGPT ile kimlik doğrulamaya izin verir; ikincisi oturum açmayı onaylı çalışma alanıyla sınırlar. Örnek UUID'yi çalışma alanınızın UUID'siyle değiştirin. Gereksinimler başvurusuna bakın.

3. Yapılandırmanın yerleştirileceği konum bölümündeki yolları kullanarak yerel requirements.toml veya macOS MDM gereksinimleri aracılığıyla dağıtın. Bu kimlik doğrulama gereksinimleri, kimlik bilgileri yüklenmeden ve bulut ilkesi alınmadan önce uygulanır; Codex bunları buluttan yönetilen gereksinimlerde yok sayar. Dosyayı ve üst dizinini kullanıcının yapabileceği değişikliklere karşı koruyun. Eski managed_config.toml varsayılanları bu kısıtlamayı zorunlu kılmaz.

4. Pilot uygulama sırasında kullanıcıların oturumlarını kapatın veya daha önce saklanan kişisel Codex oturumlarını kaldırın. Yeni bir ilkenin mevcut bir oturumu geriye dönük olarak geçersiz kıldığını varsaymayın.

5. Oturum açma kısıtlamasını çalışma alanı rolleri ve grup erişimiyle birlikte uygulayın. Kimlik doğrulama, hangi kimliğin oturum açacağını; RBAC ise bu kimliğin hangi Codex özelliklerini kullanabileceğini denetler. Kimlik doğrulama bölümüne bakın.

Doğrulayın

• Codex oturumunu kapatın.

• Kişisel bir ChatGPT hesabıyla oturum açmayı deneyin. Beklenen: Kişisel çalışma alanında oturum açma reddedilir.

• Codex'te API key ile oturum açmayı deneyin. Beklenen: API key ile oturum açma reddedilir.

• Kurumsal hesapla onaylı çalışma alanında oturum açın. Beklenen: Oturum açma başarılı olur.

• Masaüstü uygulamasını, CLI'yi ve IDE uzantısını yeniden başlatıp işlemleri tekrarlayın.

Geri alın

Önceki yerel kimlik doğrulama gereksinimlerini geri yükleyin ve incelenmiş paketi yeniden dağıtın.

Sınırlar

Bu, yönetilen uç noktalardaki yönetilen Codex istemcilerini denetler. Gereksinim “kurumsal varlıklardan kişisel Codex kullanımına izin verilmemesi” ise bunu uç nokta uygulama denetimleri ve ağ ilkesiyle birlikte uygulayın.

Geliştiriciler salt okunur veya çalışma alanıyla sınırlı erişime ihtiyaç duyduğunda ve Full Access'i seçmelerini ya da --yolo ile onayları ve korumalı alanı atlamalarını engellemek istediğinizde bu tarifi kullanın.

Amaçlanan sonuç

Kullanıcılar yalnızca onaylı salt okunur veya çalışma alanıyla sınırlı profilleri seçebilir. danger-full-access, approval_policy = "never" veya --yolo seçemezler.

Yapılandırın

1. Onaylı bir çalışma alanı profili tanımlayın:

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

2. İzin verilen profilleri ve onay ilkelerini zorunlu kılın:

   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

İzin listesi kapsamlıdır: gelecek sürümlerde eklenecek profiller de dahil olmak üzere, izin listesinde yer almayan veya false olarak ayarlanan profiller reddedilir. Yapılandırma Başvurusuna bakın.

3. Hâlâ sandbox_mode kullanan eski istemciler için şunu kullanın:

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

4. Bunu, kullanıcının düzenleyebileceği bir yapılandırma dosyası olarak değil, yönetici tarafından zorunlu tutulan gereksinimler olarak iletin.

5. Daha sonra Auto-review kullanımına izin verirseniz bunu test ettikten sonra bilinçli olarak ekleyin. Auto-review, bir sınırın aşılmasını kimin inceleyeceğini değiştirir; kaldırılmış bir sınırı geri getirmez. Auto-review bölümüne bakın.

Doğrulayın

• İzin seçiciyi açın. Beklenen: Full Access kullanılamaz veya reddedilir.

• --dangerously-bypass-approvals-and-sandbox ile başlatın. Beklenen: Codex başlatmayı reddeder veya uyumlu bir profili zorunlu kılar.

• --sandbox danger-full-access --ask-for-approval never ile başlatın. Beklenen: Başlatma reddedilir.

• Normal bir çalışma alanı görevi çalıştırın. Beklenen: Görev başarılı olur; sınırların aşılması için yine onay gerekir.

Geri alın

Önceki gereksinim paketini geri yükleyin. Ayrı olarak onaylanmış bir istisna yoksa sınırsız erişimi engellemeye devam edin.

Sınırlar

Bu, Codex çalışma zamanı izinlerini denetler. Ayrıcalıklı bir işletim sistemi hesabını ayrıcalıksız hâle getirmez.

Kuruluşunuzun Codex'in hangi MCP server'ları kullanabileceğine karar vermesi ve onaylı bir listeyi zorunlu kılması gerektiğinde bu tarifi kullanın.

Bir sunucuya izin vermek ve onu yapılandırmak ayrı adımlardır. İzin listesi girdisi, eşleşen bir sunucuya izin verir; sunucu yapılandırmasını oluşturmaz. Sunucuyu, eşleşen ad ve kimlikle ve gerektirdiği kimlik doğrulamayla birlikte ayrıca yapılandırın.

Amaçlanan sonuç

Codex, yalnızca yapılandırılmış adı ve kimliği kurum tarafından onaylanan listeyle eşleşen MCP server'ları etkinleştirir.

Yapılandırın

1. Onaylı her sunucunun envanterini çıkarın: sorumlusu, amacı, aktarım yöntemi, tam yürütülebilir dosyası veya URL'si, kimlik doğrulaması, veri sınıflandırması ve yazma yeteneği olan araçları.

2. Tümünü reddederek başlayın. Boş bir yönetilen tablo tüm MCP server'ları devre dışı bırakır:

   [mcp_servers]

3. Onaylı HTTP sunucularını tam URL'leriyle ekleyin:

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

4. Onaylı stdio sunucularını yürütülebilir dosya ve konumsal argümanlarıyla ekleyin:

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

Yapılandırılmış eşleştirici, yürütülebilir dosyayı, argüman sayısını ve argüman sırasını kontrol eder. cwd, env veya env_vars öğelerini kısıtlamaz. Başlatma bağlamının tamamının denetlenmesini bir stdio sunucusunu onaylamanın ön koşulu olarak ele alın: yürütülebilir dosyasını ve bağımlılıklarını koruyun ve güvenilmeyen kullanıcı veya proje yapılandırmasının, davranışını değiştirebilecek bir çalışma dizini veya ortam sağlamasını engelleyin. Bu sınırı bağımsız olarak uygulayamıyorsanız stdio sunucusunu onaylamayın ve bunun yerine incelenmiş bir HTTP sunucusu kullanın.

5. Eklentilerle birlikte gelen MCP kimliklerini plugins.<plugin>.mcp_servers.<server> altında ayrıca ekleyin.

6. Onaylı listeyi incelenmiş bir yapılandırma deposunda saklayın ve yönetici tarafından zorunlu tutulan gereksinimler aracılığıyla dağıtın.

İstemci, bir sunucuyu yalnızca hem adı hem de kimliği onaylı bir girdiyle eşleştiğinde etkinleştirir. Yönetilen yapılandırma bölümüne bakın.

Doğrulayın

• Onaylı sunucuyu tam olarak belirtilen şekilde yapılandırın. Beklenen: Sunucu başlar.

• URL'deki bir karakteri değiştirin. Beklenen: Sunucu devre dışı bırakılır.

• stdio argüman sayısını veya sırasını değiştirin ya da yapılandırılmış argüman kurallarının dışında bir argüman sağlayın. Beklenen: Sunucu devre dışı bırakılır. İzin verilen bir öneki karşılamaya devam eden değerlere izin verilir.

• Testten sonra silinebilecek güvenilir bir projede, eşleşen yürütülebilir dosyayı ve argümanları koruyarak zararsız cwd, env ve env_vars geçersiz kılmalarını deneyin. Kimlik eşleştirmesi tek başına bu geçersiz kılmaları reddetmez. Bağımsız başlatma bağlamı denetiminizin güvenli olmayan geçersiz kılmaları reddettiğini veya stdio sunucusunun onaylanmamış olarak kaldığını doğrulayın; gerçek bir enjeksiyon yükü kullanmayın.

• Onaylanmamış bir ad ekleyin. Beklenen: Sunucu devre dışı bırakılır.

• Bir eklentiyle birlikte gelen sunucuyu test edin. Beklenen: Sunucu yalnızca onaylı kimlikle çalışır.

Geri alın

Yeni eklenen girdiyi kaldırın. Tüm MCP kullanımını hemen durdurmak için boş bir mcp_servers tablosu dağıtın.

Sınırlar

Kimliklerin izin listesine alınması, bir sunucunun araçlarının, üst kaynaklardan gelen verilerinin, kimlik bilgilerinin veya başlatma ortamının güvenli olduğunu kanıtlamaz. Yerel stdio MCP süreçleri, yerel komut korumalı alanının dışında çalışır; bir yürütülebilir dosya ve argümanların eşleşmesi, sunucunun erişimini kısıtlamaz veya ortam üzerinden kod yüklenmesini engellemez. Başlatma bağlamının tamamını ve sunucu izinlerini bağımsız olarak inceleyin. MCP kimlik gereksinimleri bölümüne bakın.

Güvenlik ekibinizin Codex'in uç noktalarda ve ağınızda ne yaptığını anlaması gerektiğinde bu tarifi kullanın. Bu tarif, incelemeler için çalıştırma ve araç olaylarını, onay kararlarını, çalışma alanı denetim kayıtlarını ve ağ günlüklerini bir araya getirir.

Amaçlanan sonuç

Güvenlik ekipleri, modelin kendi anlatımına dayanmadan Codex çalıştırmalarını, araç kararlarını, onayları, çalışma alanı denetim kayıtlarını ve gerçek dış ağ trafiğini ilişkilendirebilir.

Dört kanıt kaynağı kullanın

1. Codex OpenTelemetry: çalıştırma, API, model, korumalı alan, onay ve araç olayları.

2. Yönetilen yaşam döngüsü kancaları: araç kullanımı ve izin istekleriyle ilgili uç nokta tarafındaki kayıtlar.

3. Ağ proxy'si veya ağ geçidi günlükleri: gerçek DNS/HTTP hedefleri ve bağlantı sonuçları.

4. Compliance API: çalışma alanı düzeyinde denetim ve inceleme kayıtları.

Hiçbir kaynak tek başına tam ağ izlemesi sağlamaz.

Yapılandırın

1. Ham prompt'ları gizleyerek Codex OpenTelemetry günlüklerini toplayıcınıza gönderin:

   [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}" }

İstemciyi başlatmadan önce, onaylı gizli bilgi yöneticiniz veya süreç ortamı aracılığıyla Codex sürecine OTLP_TOKEN sağlayın. Belirteci dağıtılan TOML dosyalarında ve kaynak denetiminde tutmayın.

Codex; konuşma başlangıçlarını, API isteklerini, akış olaylarını, prompt meta verilerini, araç kararlarını ve araç sonuçlarını üretebilir. Gelişmiş Yapılandırma bölümüne bakın.

2. OTel'i projeye yerel yapılandırmanın dışında dağıtın. Projedeki .codex/config.toml dosyaları telemetri yönlendirmesini geçersiz kılamaz.

3. SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop ve SessionEnd için yönetilen yaşam döngüsü kancaları ekleyin.

4. Kanca betiklerini yönetici tarafından yönetilen bir dizine yükleyin ve kullanıcı, proje ve eklenti kancalarının yok sayılması gerekiyorsa allow_managed_hooks_only = true ayarını yapın.

5. Korumalı alandaki komut trafiğini, bağımsız olarak günlük tutan bir proxy üzerinden yönlendirin. OTel bir aracın çalıştığını; proxy ise alt sürecin nereye bağlanmaya çalıştığını kaydeder.

6. Web araması, uygulamalar, bağlayıcılar, MCP server'lar, tarayıcı etkinliği ve Codex Cloud için ayrı telemetri yapılandırın. Yerel komut proxy kuralları bunları otomatik olarak kapsamaz.

7. Desteklenen Compliance API kayıtlarını SIEM'e akış hâlinde aktarın ve kendi saklama ve yasal muhafaza denetimlerinizi uygulayın. Compliance API ve denetim olayları bölümüne bakın.

8. Kullanıcı veya hizmet hesabını, ana makineyi veya çalıştırıcıyı, konuşma kimliğini, modeli, istemci sürümünü, izin profilini, onay kararını, hedefi ve araç adını ilişkilendirin.

Doğrulayın

Aşağıdakileri yapan kontrollü bir oturum çalıştırın:

• İzin verilen bir dosyayı okur.

• Engellenen bir dosyayı okumayı dener.

• İzin verilen bir komutu çalıştırır.

• Engellenen bir dış ağ isteği göndermeyi dener.

• Onay ister ve ret yanıtı alır.

• Oturumu sonlandırır.

Kanıt kaynağına göre beklenen sonuçlar:

• OTel, çalıştırma ve araç olaylarını gösterir.

• Kancalar, oturum yaşam döngüsünü gösterir.

• Proxy günlükleri, izin verilen ve engellenen hedefleri gösterir.

• Uyumluluk verilerini içeri alma süreci, desteklenen kayıtları alır.

• SIEM, bu kayıtları kullanıcı veya iş yüküyle ilişkilendirir.

Geri alın

Önceki yapılandırmayı geri yükleyerek dışa aktarıcıyı ve kancaları devre dışı bırakın. Telemetriyi geri alma işleminin parçası olarak bağımsız proxy günlük kaydını kaldırmayın.

Sınırlar

Codex telemetrisinin her komut argümanını, çıktı baytını veya ağ paketini yakaladığını taahhüt etmeyin. Her katmanın kapsamını belgeleyin.

Codex'in internet erişiminin olmaması veya yalnızca onaylı hedeflere ulaşması gerektiğinde bu tarifi kullanın. Yapılandırdığınız ortam için yerel veya bulut prosedürünü seçin ve bunların ayrı ilke kapsamlarını göz önünde bulundurun.

Amaçlanan sonuç

Codex, seçtiğiniz yapılandırmaya göre internet erişimine sahip olmaz veya yalnızca onaylı alan adlarına ulaşır. Codex Cloud (Legacy) ortamları ayrıca HTTP yöntemlerini kısıtlayabilir.

Güncel Codex Cloud'u yapılandırın

1. no-internet-review, approved-dependencies-build ve cyber-lab gibi farklı güven düzeyleri için ayrı ortamlar oluşturun.

2. Ortam yapılandırmasında, iş akışı internet erişimi gerektirmedikçe Allow Codex to access internet seçeneğini kapalı bırakın.

3. Erişim gerektiğinde Allow Codex to access internet seçeneğini açın. Allow domains altında Custom domains only seçeneğini belirleyin, ardından Additional allowed domains altında gereken ana makineleri tam olarak ekleyin.

4. Kurulum sırasında hizmetleri kaydedin ve test edin. Ortamı yayımlayın veya yeniden yayımlayın, ardından yeni bir görevde onaylı ve onaylanmamış hedeflere erişimi test edin. Kurulum betiklerini ayrıca inceleyin: bağımlılıkları belirli sürümlere sabitleyin, onaylı yansıları tercih edin ve incelenmemiş yürütülebilir dosyaları indirmekten kaçının.

Hizmetlere bağlanma bölümüne bakın. Güncel Codex Cloud ayarları, Legacy HTTP yöntemi seçicisini sunmaz.

Codex Cloud (Legacy) ortamını yapılandırın

1. Gereksiz olduğunda ajanın internet erişimini Off konumunda tutun. Legacy Cloud, ajan aşamasında interneti varsayılan olarak engeller; kurulum betikleri ise bağımlılık yüklemek için internet erişimiyle çalışmaya devam eder.

2. Ajan erişimi gerektiğinde dar kapsamlı bir izin listesiyle On konumuna getirin. None ile başlayın ve tam alan adlarını ekleyin.

3. Yalnızca indirme yapılan iş akışlarında sadece GET, HEAD ve OPTIONS yöntemlerine izin verin. Bu, POST, PUT, PATCH, DELETE ve diğer yöntemleri engeller. Ajan aşamasındaki kısıtlama kurulum betiklerinin internet erişimini yönetmediğinden bu betikleri ayrıca inceleyin.

Eski ajan internet erişimi bölümüne bakın. Bu ön ayarlar ve HTTP yöntemi denetimleri yalnızca Legacy Cloud için geçerlidir.

Yerel Codex'i yapılandırın

1. Yönetici tarafından yönetilen requirements.toml içinde onaylı ağ profilini tanımlayıp seçin ve kullanıcıları bu profille sınırlayın:

   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. İncelenmiş gereksinim paketini Yönetilen yapılandırma yönergelerini kullanarak dağıtın. Adlandırılmış bir profil tek başına etkin değildir; default_permissions bu profili seçer ve izin listesi diğer profillerin seçilmesini engeller.

3. Alan adı kısıtlamalarının uygulanması ve kullanıcıların bunları genişletememesi için yönetici tarafından yönetilen proxy'yi aynı gereksinim paketinde etkinleştirin. Proxy'yi ve ağ erişimi etkin profili birlikte dağıtın; etkin bir proxy olmadan ağ erişimi etkin bir profil, alan adı kurallarını uygulamadan doğrudan ağ erişimi sağlar:

   Dikkat: [experimental_network] deneyseldir ve değişebilir. Daha geniş çaplı kullanıma sunmadan önce desteklenen her yerel istemci sürümünde ve işletim sisteminde doğrulayın. Windows desteği sınırlıdır; ortamınızda kısıtlamaların uygulandığını test edene kadar bu ilkeyi Windows kullanıcılarına uygulamayın.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

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

4. İş akışı gerektirmedikçe yerel bağlantı noktalarına bağlanmayı kapalı tutun. Özel ağ hedeflerine erişimi ayrıca yapılandırın; bir alan adına izin vermek, onun özel adreslerini tek başına onaylamaz. Ağ erişimi gereksinimleri bölümüne bakın.

5. Web aramasını, uygulamaları, MCP server'ları, tarayıcı etkinliğini ve Codex Cloud'u ayrıca yapılandırın. Yerel korumalı alan kuralları bunları denetlemez.

Doğrulayın

• Onaylı bir alan adına istek gönderin ve başarılı olduğunu doğrulayın.

• Onaylanmamış bir alan adına istek gönderin ve engellendiğini doğrulayın.

• localhost, özel bir IP ve bir bulut meta veri uç noktasına istek gönderin. Açıkça onaylanmadığı sürece her isteğin engellendiğini doğrulayın.

• Codex Cloud (Legacy) ortamında izin verilen bir alan adına POST isteği göndermeyi deneyin. Yalnızca GET, HEAD ve OPTIONS yöntemlerine izin verildiğinde isteğin engellendiğini doğrulayın.

• Proxy veya ağ geçidi günlüklerinin hem izin verilen hem de reddedilen istekler için girdiler içerdiğini doğrulayın.

Geri alın

Ortamı Off konumuna döndürün veya önceki alan adı ilkesini geri yükleyin. Sınırsız internet erişimine geri dönmekten kaçının.

Sınırlar

Onaylanmış tam korumalı alan yetki yükseltmesi, yerel komut proxy'sini atlayabilir. Kısıtlamaya güvenmeden önce normal korumalı alan komutlarını ve onaylanmış yükseltilmiş yetkili komutları ayrı ayrı test edin.

İzin verilen bir alan adı yine de prompt enjeksiyonu, ele geçirilmiş paketler veya güvenli olmayan belgeler barındırabilir.

Codex'in onaylı kaynak dizinlerine erişmesi gerekirken gizli bilgilerin, .env dosyalarının, SSH anahtarlarının ve ilgisiz depoların erişim dışında kalması gerektiğinde bu tarifi kullanın. Bu tarif, dosya erişimini kısıtlamayı ve başlatılan komutlara aktarılan, kimlik bilgisi içeren ortam değişkenlerinin sayısını azaltmayı kapsar.

Amaçlanan sonuç

Codex, onaylı kaynak dizinlerinde çalışabilir ancak yaygın olarak gizli bilgi içeren dosyaları okuyamaz veya kimlik bilgisi içeren geniş bir ortam değişkeni kümesini devralamaz.

Yapılandırın

1. Bir çalışma alanı profilinde okumayı reddetme kalıpları tanımlayın:

   [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. Bilinen kimlik bilgisi dizinleri, imzalama anahtarları, üretim yapılandırması ve komşu depolar için erişimi reddedilecek tam yolları ekleyin.

3. Sistem düzeyindeki /etc/codex/config.toml veya kullanıcıya ait ~/.codex/config.toml içinde, başlatılan komutlara aktarılan ortam değişkenlerini azaltın:

   [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"

Bu, zorunlu bir gereksinim değil, kullanıcı tarafından yapılandırılabilen bir varsayılandır. Devralınan değişkenleri azaltır ancak kimlik bilgisi dosyalarına, yardımcı araçlara, kabuk başlangıç içeriğine veya diğer kimliklere erişimi engellemez. Gelişmiş Yapılandırma bölümüne bakın.

4. Yönetici tarafından yönetilen requirements.toml içinde kısıtlı profili seçin ve yalnızca bu profile izin verin. Yerleşik profiller, bu profilin gizli bilgi dosyalarına yönelik ret kurallarını devralmaz:

   default_permissions = "corp-workspace"

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

5. Cloud ortamınız için kimlik bilgisi akışını seçin:

   • Güncel Codex Cloud'da, izin verilen bir HTTPS hizmetine gönderilen kimlik bilgileri için Network secrets kullanın. Programlar bir yer tutucu alır; proxy, kurulum ve görevler sırasında 443 numaralı bağlantı noktasındaki onaylı hedefler için gerçek değeri bunun yerine koyar. Ham kimlik bilgisi yerel bir sürece veya dosyaya yerleştirilmez. Doğrudan ortam değişkenleri programlar tarafından kullanılabilir. Ortam değişkenleri ve ağ gizli bilgileri bölümüne bakın.
   • Codex Cloud (Legacy) ortamında gizli bilgiler, kurulum sırasında kimlik doğrulamayı destekler ve ajan aşamasından önce kaldırılır; ortam değişkenleri ise sohbetin tamamı boyunca kalır. Eski Cloud ortamları bölümüne bakın.

6. Ajanın kimlik doğrulamaya ihtiyacı varsa tam hedef ve eylemle sınırlı kısa ömürlü kimlik bilgileri sağlamak için bağımsız bir aracı kullanın. Önerilen yapılandırma bölümüne bakın.

Doğrulayın

Zararsız test dosyaları ve değişkenleri oluşturun:

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

Ardından Codex'ten şunları isteyin:

• Normal bir dosyayı okumasını.

• Her test dosyasını okumasını.

• Gizli bilgileri alt dizinler dahil aramasını.

• Komut ortamını yazdırmasını.

• Komşu bir depoyu okumasını.

Beklenen: Normal bir dosyanın okunması başarılı olur; erişimi reddedilen dosyalar ve komşu depolar erişilemez kalır ve dışlanan değişkenler komut ortamında bulunmaz.

Geri alın

Önceki profili geri yükleyin ancak iş akışı hatalarını incelerken gizli bilgi dosyalarına yönelik doğruluğundan emin olduğunuz ret kurallarını koruyun.

Sınırlar

Dosya sistemi ret kuralları; prompt'lara zaten yapıştırılmış, okunabilir kaynak koduna işlenmiş, bağlayıcılar tarafından döndürülmüş veya modelin erişebildiği günlüklere yazılmış gizli bilgileri kaldırmaz.

git push, dağıtımlar, veritabanı geçişleri ve bulut CLI komutları gibi eylemlerin çalıştırılmadan önce onay gerektirdiği durumlarda bu tarifi kullanın. Hangi komutların inceleme istemi göstermesi, hangilerinin yasaklanması gerektiğine karar verin, ardından bu komutlar için kurallar yapılandırın.

Amaçlanan sonuç

Hassas komutlar, model bunların uygun olduğuna inansa bile tutarlı biçimde onay için duraklatılır veya yasaklanır.

Yapılandırın

1. Hangi komutların onay istemi gerektirdiğine, hangilerinin yasak olduğuna karar verin.

2. Yönetici tarafından zorunlu tutulan komut kuralları ekleyin:

   [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." },
   ]

Gereksinim kuralları, onay istemini zorunlu kılabilir veya bir komutu yasaklayabilir; bir komuta izin veremez. Yönetilen yapılandırma bölümüne bakın.

3. Yüksek riskli profillerde, sarmalayıcıların hassas bir komutu gizleyebileceği durumlarda aynı prefix_rules dizisine bir kabuk sarmalayıcısı girdisi ekleyin:

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

Kabuk sarmalayıcısı girdisi çok sayıda uyarı üretir; seçici biçimde kullanın.

4. Komutları bir kişinin onaylaması gerekiyorsa şu ayarları zorunlu kılın:

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

Auto-review, incelemeyi yapanı değiştirir; deterministik bir güvenlik garantisi değildir. Auto-review bölümüne bakın.

5. PermissionRequest, araç kararı ve araç sonucu olaylarını güvenlik işlem hattına gönderin.

Doğrulayın

• git status çalıştırın. Beklenen: Onay istemi görünmez.

• git push çalıştırın. Beklenen: Onay istemi görünür.

• terraform apply çalıştırın. Beklenen: Onay istemi görünür.

• kubectl delete pod test çalıştırın. Beklenen: Onay istemi görünür.

• rm -rf test-directory çalıştırın. Beklenen: Komut yasaklanır.

• Bir onay isteğini reddedin. Beklenen: Komut çalışmaz ve ret kararı günlüğe kaydedilir.

• İstemciyi yeniden başlatıp kontrolleri tekrarlayın. Beklenen: Kural uygulanmaya devam eder.

Geri alın

Önceki gereksinim paketini geri yükleyin. Hassas komut sınıfının tamamını kaldırmak yerine aşırı geniş bir belirteç kalıbını daraltın.

Sınırlar

Önek kuralları, eksiksiz bir işletim sistemi ilke motoru değildir. Bunları korumalı alan, en az ayrıcalıklı işletim sistemi hesapları, ağ kısıtlamaları, bulut IAM, dal koruması, dağıtım onayları ve veritabanı yetkilendirmesiyle birlikte uygulayın.

Şu yapılandırma tariflerini kullanır: İzin profillerini ve Full Access'i kısıtlayın; Gizli bilgileri ve ilgisiz depoları koruyun; Hassas komutlar için onay isteyin.

Geliştiricilerin üretim ortamına meşru erişimi vardır ancak Codex'in incelenmemiş üretim değişiklikleri yapmadan geliştirmeye yardımcı olmasını istersiniz.

• Onaylı bir çalışma alanı profili tanımlayın ve izin verilen profilleri ve onay ilkelerini zorunlu kılın. Kullanıcıların bunları geçersiz kılmasını önlemek için bu ayarları yönetici tarafından zorunlu tutulan gereksinimler olarak iletin.

• Codex'i ayrı ve daha düşük ayrıcalıklı bir kimlikle ya da üretim ortamına yazma yetkisi veren kimlik bilgilerine erişemeyen veya bunları edinemeyen bir ortamda çalıştırın. Geliştiriciler, ayrı bir yetkili iş akışı üzerinden üretim erişimlerini sürdürebilir.

• Başlatılan komutlara aktarılan ortam değişkenlerini en aza indirin. Ajanın kimlik doğrulamaya ihtiyacı varsa tam hedef ve eylemle sınırlı kısa ömürlü kimlik bilgileri sağlamak için bağımsız bir aracı kullanın.

• Hangi komutların onay istemi gerektirdiğine, hangilerinin yasak olduğuna karar verin. git push, terraform apply, Kubernetes değişiklikleri ve veritabanı geçişleri gibi yüksek etkili seçili komutların bir kişi tarafından onaylanmasını zorunlu kılın; asla çalıştırılmaması gereken komutları yasaklayın.

• Üretim IAM, dal koruması ve dağıtım onaylarını Codex'ten bağımsız olarak uygulamaya devam edin.

İzin profillerini kısıtlayın ve insan incelemesini zorunlu kılın

Yönetici tarafından yönetilen requirements.toml içinde yerleşik çalışma alanı ve salt okunur profillere izin verin ve onay gerektiren eylemler için kullanıcı incelemesini zorunlu kılın:

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

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

Çalışma alanı profili, korumalı alanı içinde çalışma alanında çalışmaya izin verir; salt okunur profil ise daha dar kapsamlı işler için kullanılabilir. Tam erişim profilleri izin listesinde yer almaz.

İstemcinin açıkça belirtilmiş uyumlu bir seçeneğe ihtiyacı varsa istemci yapılandırmasında approval_policy = "on-request" ayarını yapın. on-request, gerektiğinde onay istemi gösterilmesine izin verir; her komut için onay istemez. İnceleme gerektiren eylemler için açık kurallar ekleyin ve bağımsız üretim yetkilendirmesini koruyun.

Yönetilen profil izin listeleri, Codex 0.138.0 veya sonraki bir sürümü gerektirir; daha eski istemciler için belgelenmiş eski korumalı alan modu gereksinimlerini kullanın ve test edin.

Her pilot istemciyi yeniden başlatın, onaylı profilin çalıştığını ve izin verilmeyen bir tam erişim profilinin reddedildiğini doğrulayın.

Codex kimliğini üretim kimlik bilgilerinden ayırın

Cihaz yönetimi veya geliştirme ortamı sağlama sisteminizde, yalnızca ihtiyaç duyduğu kaynak koduna ve geliştirme hizmetlerine erişebilen özel bir Codex kullanıcısı, kapsayıcısı veya geliştirme ana makinesi oluşturun. Geliştiricinin üretim kimlik bilgisi dosyalarını, belirteç yardımcılarını veya anahtar zincirlerini bu ortama bağlamayın ve kimliğin üretim ortamına yazma rolleri edinmesini engelleyin.

Ajanın hizmet erişimine ihtiyacı varsa kuruluşunuzun kimlik bilgisi aracısını, geliştirme kaynağı ve eylemiyle sınırlı kısa ömürlü kimlik bilgileri verecek şekilde yapılandırın. Geliştirici, ayrı bir yetkili üretim iş akışı üzerinden normal kimliğini kullanabilir.

Örneğin AWS IAM'de Roles bölümünü açın, Codex geliştirme rolünü seçin ve Permissions altında, hesap ve rolü kendinizinkilerle değiştirerek aşağıdaki gibi incelenmiş bir satır içi ilke ekleyin:

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

Bu örnek, belirtilen rolü üstlenme girişimlerini reddeder ancak diğer rolleri üstlenme girişimlerini reddetmez. Ayrıca doğrudan üretim izinlerini kaldırın, diğer üretim rollerini ve kimlik bilgisi kaynaklarını kısıtlayın ve güven ilkeleriyle kuruluş düzeyindeki denetimleri inceleyin.

Üretim ortamında değişiklik yapmadan, geliştirme rolünü temsili geliştirme ve üretim izinleriyle test edin. Bkz. AWS IAM rol ilkesi örnekleri.

Kabuk ortamını en aza indirin

Sistem genelinde bir başlangıç yapılandırması için /etc/codex/config.toml dosyasında veya tek bir kullanıcı için ~/.codex/config.toml dosyasında, başlatılan komutların hangi ortam değişkenlerini devralacağını yapılandırın:

[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"

Bu, yapılandırılabilir bir varsayılandır; zorunlu olarak uygulanan bir kimlik bilgisi sınırı değildir. Kullanıcı ayarları, kabuk başlangıç işlemleri veya anlık görüntüleri, kimlik bilgisi yardımcıları ve diğer kimlik bilgisi kaynakları, kimlik bilgilerini yine de erişime açabilir.

İş akışınızla uyumluysa, oturum açma kabuklarını ve kabuk anlık görüntülerini devre dışı bırakmak için requirements.toml dosyasında aşağıdaki isteğe bağlı kısıtlamaları kullanın:

allow_login_shell = false

[features]
shell_snapshot = false

Bazı iş akışları oturum açma kabuğunun başlatılmasına bağlı olduğundan bu ayarları pilot olarak uygulayın.

Codex'i filtrelerle eşleşen zararsız, sentetik değişkenlerle başlatın ve başlatılan bir komutun ortamını inceleyin; ayrıca oturum açma kabuğu devre dışı bırakılmışsa buna yönelik isteğin reddedildiğini doğrulayın. Yürütme kimliğinin gerçek üretim kimlik bilgilerine erişemediğini bağımsız olarak doğrulayın. Bkz. Kabuk ortamı ilkesi.

Seçili yüksek etkili komutlar için onay isteyin

Kuruluşunuzun kullandığı komutlar için gereksinim kuralları ekleyin. Örneğin:

[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." },
]

Asla çalıştırılmaması gereken bir komut için forbidden kullanın; örüntüleri kullanılan gerçek dağıtım ve geçiş araçlarına göre değiştirin veya yeni örüntüler ekleyin.

Bu kurallar komut önekleriyle eşleşir ve eşdeğer tüm eylemleri kapsamaz. Mutlak yolları, sarmalayıcıları, farklı bağımsız değişken sıralamalarını, diğer istemcileri ve diğer araçları ayrı ayrı test edin.

Geçici bir hedefte normal bir komut çalıştırın, listelenen bir eylemi isteyin, onay isteğini reddedin ve eylemin yürütülmediğini doğrulayın. Bkz. Komut kurallarını zorunlu kılma.

Depo ve dağıtım onaylarını Codex dışında zorunlu kılın

Kaynak kontrol platformunuzda main gibi üretim dallarını koruyun: değişikliklerin incelenmesini, gerekli onayları ve durum denetimlerini zorunlu kılın ve hangi rollerin bu gereksinimleri atlayabildiğini inceleyin. Dağıtım onayını ilgili dağıtım sisteminde, veritabanı ayrıcalıklarını ise veritabanının kendisinde yapılandırın.

İncelenmiş bir değişikliğin uygulanabildiğini ve yetkisiz doğrudan gönderimin reddedildiğini doğrulamak için geçici bir depo kullanın. Bu denetimler, bir eylemin Codex üzerinden istenip istenmediğinden bağımsız olarak geçerlidir.

Doğrulayın

Geçici bir test hedefinde:

• Normal bir çalışma alanı görevi çalıştırın. Beklenen: Görev başarıyla tamamlanır.

• Temsili bir hassas komutu çalıştırmayı deneyin ve onay isteğini reddedin. Beklenen: Reddedilen komut çalışmaz.

• Codex kimliğinin üretim ortamında yazma erişimi elde edemediğini doğrulayın.

• İstemciyi yeniden başlatın ve tekrarlayın.

Sınırlar

Önek kuralları, eksiksiz bir işletim sistemi ilkesi motoru değildir. Bunları korumalı alan, en az ayrıcalıklı işletim sistemi hesapları, ağ kısıtlamaları, bulut IAM, dal koruması, dağıtım onayları ve veritabanı yetkilendirmesiyle birlikte kullanın.

Şu yapılandırma tariflerini kullanır: Gizli bilgileri ve ilgisiz depoları koruyun; Ağ hedeflerini kısıtlayın; Yalnızca onaylı MCP server'lara izin verin; Hassas komutlar için onay gerektirin.

Geliştiriciler Codex'i kurum içi depolarla kullanıyor ve kodun herkese açık bir depoya, herkese açık bir kod parçacığına veya onaylanmamış başka bir hedefe gönderilmesi riskini azaltmak istiyorsunuz.

• Bilinen kimlik bilgisi dizinleri ve ilgisiz depolar için erişimi reddedilecek tam yollar ekleyin ve başlatılan komutlara aktarılan ortam değişkenlerini en aza indirin.

• Ajanın internet erişimi gerektiğinde, onaylı alan adlarından oluşan dar kapsamlı bir izin listesi kullanın. Yalnızca onaylı MCP server adlarına ve kimliklerine izin verin ve git push gibi seçili yayımlama komutları için inceleme zorunluluğu getirin veya bu komutları reddedin.

• Kuruluşunuza uygun kaynak kontrol kancaları ve izinleri, herkese açık depolar ve kod parçacıkları için ilkeler ve veri kaybı önleme denetimleri kullanın.

İlgisiz depolara ve kimlik bilgisi dosyalarına erişimi reddedin

Yönetici tarafından yönetilen requirements.toml dosyasına, yerel ajanın okumaması gereken tam yolları ekleyin:

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

Örnekleri, yönetilen cihazlarınızda bulunan yollarla değiştirin. Yönetilen bu erişim reddi, izin verilen tüm izin profillerinde geçerlidir; yalnızca tek bir özel profil içinde yapılandırılan erişim reddi, farklı bir profil seçen kullanıcıları korumaz. Bilinen tam yolları tercih edin ve glob örüntülerini ihtiyaç duyduğunuz dizin derinliklerinde test edin.

Yerel Windows ortamında, yönetilen deny_read doğrudan dosya araçlarını kapsar ancak tek başına kabuk alt süreçlerinin okuma işlemlerini engellemez; işletim sistemi kimliklerini ve dosya erişim denetim listelerini de kullanın.

Erişimi reddedilen konumlarda zararsız test dosyaları oluşturun. İzin verilen her profilde, bu dosyaların hem doğrudan hem de kabuk üzerinden okunmasının reddedildiğini ve onaylı bir kaynak dosyasının okunabildiğini doğrulayın. Bkz. Yönetilen okuma reddi gereksinimleri.

Kimlik bilgisi içeren kabuk değişkenlerini en aza indirin

/etc/codex/config.toml veya ~/.codex/config.toml dosyasında, devralınan ortamı dar kapsamlı olacak şekilde ayarlayın:

[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"

Bu ayar, devralınan değişkenleri azaltır ancak kullanıcı tarafından yapılandırılabilir ve kimlik bilgisi dosyalarına, yardımcılara, kabuk başlangıç içeriğine veya diğer kimliklere erişimi engellemez.

Uygun durumlarda bir yönetici, geliştirici iş akışları üzerindeki etkilerini değerlendirmek için bu kısıtlamaları requirements.toml dosyasına ekleyip pilot olarak uygulayabilir:

allow_login_shell = false

[features]
shell_snapshot = false

Sentetik test değişkenleri ve ayrı bir en az ayrıcalıklı yürütme kimliğiyle test edin. Gerçek kimlik bilgilerini kullanmayın. Bkz. Kabuk ortamı ilkesi.

Yerel komutlar için yalnızca onaylı ağ hedeflerine izin verin

Korumalı alandaki yerel komutların ağ erişimine ihtiyacı varsa, aşağıdaki profil ve yönetilen proxy ayarlarının her ikisini de requirements.toml dosyasına birleştirin ve alan adlarını onaylı uç noktalarla değiştirin:

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"

Ağ erişimi etkin profil, korumalı alandaki komuta bir ağ yolu sağlarken yönetilen proxy, komutun hedeflerini kısıtlar. Bunları birlikte dağıtın; amaçlanan yönetilen proxy olmadan ağ erişimi etkin bir profil, aynı hedef kısıtlamalarını uygulamaz. İnternet erişimi gerekmiyorsa ağ erişimini devre dışı bırakın.

Standart domains tablosunu eski allowed_domains veya denied_domains ayarlarıyla birleştirmeyin; mevcut ilkeyi taşıyın ve test edin.

İstemciyi yeniden başlatın ve onaylı bir uç noktanın çalıştığını, onaylanmamış bir uç noktanın ise engellendiğini doğrulayın.

Bu ayarlar deneyseldir; işletim sistemi ve istemci desteğini doğrulayın ve onaylı bir ana makine özel bir adrese çözümleniyorsa özel ağ erişimini ayrı olarak yapılandırın. Onaylanmış bir tam korumalı alan yetki yükseltmesi, komut proxy'sini atlayabilir.

Yerel komutlara yönelik bu ağ denetimi, tek başına web aramasını, uygulamaları, MCP server'ları, tarayıcı etkinliğini veya bulut ortamlarını kapsamaz; bunlar için ayrı ilkeler gerekir. Onaylı bir barındırma alan adı, herkese açık depolar veya herkese açık kod parçacıkları da içerebilir; dolayısıyla yalnızca hedef izin listesi kullanmak içerik koruması sağlamaz. Bkz. Ağ erişimi gereksinimleri.

Bulut ortamı ağını ayrı olarak yapılandırın

Mevcut Codex Cloud arayüzünde ortam yapılandırmasını açın. Allow Codex to access internet seçeneğini kapalı bırakın. İnternet erişimine ihtiyacınız varsa bu seçeneği açın, Custom domains only seçeneğini belirleyin, Additional allowed domains altına gereken tam ana makine adlarını ekleyin, ardından yapılandırmayı kaydedin, ortamı yayımlayın veya yeniden yayımlayın ve yeni bir görevle test edin.

Hizmet kimlik doğrulamasını ve yeteneklerini bağımsız olarak inceleyin.

Eski Codex Cloud, izin verilen alan adları ve HTTP yöntemlerine yönelik denetimler içeren, ortam başına ayrı bir ajan internet ayarı kullanır; kurulum betiklerinin kendilerine özgü erişim davranışı vardır.

Gerçekte kullandığınız ortam sürümünü test edin. Bkz. Hizmetlere bağlanma ve eski internet ayarları.

MCP server'ları kısıtlayın ve Git gönderimlerinden önce onay isteyin

requirements.toml dosyasında yalnızca onaylı yerel MCP server kimliklerine izin verin. Örneğin:

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

Asıl sunucuyu, eşleşen ad ve URL'yi ve sunucunuzun gerektirdiği kimlik doğrulamasını kullanarak kullanıcıya ait veya yönetilen varsayılan config.toml dosyasında ayrı olarak yapılandırın:

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

Bu gereksinim yalnızca eşleşen bir sunucuya izin verir ve sunucuyu oluşturmaz. Sunucunun kendi erişimini ve araçlarını inceleyin.

Onaylı sunucunun bağlanabildiğini ve farklı bir ada veya URL'ye sahip bir sunucuya izin verilmediğini doğrulayın.

Temsili bir yayımlama komutundan önce inceleme istemek için yönetilen bir komut kuralı ekleyin:

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

İncelemeyi bir kişinin yapması gerekiyorsa, bunu üst düzey gereksinimler olarak allowed_approval_policies = ["on-request"] ve allowed_approvals_reviewers = ["user"] ile birlikte kullanın.

Bir test gönderimini reddedin ve çalışmadığını doğrulayın.

Önek eşleştirme her sarmalayıcıyı, API istemcisini, uygulamayı veya alternatif yayımlama yolunu kapsamaz.

Kaynak kontrolü ve DLP denetimleriyle herkese açık yayımlamayı kısıtlayın

Kaynak kontrol platformunuzda, desteklendiği ölçüde, herkese açık depo oluşturmayı kısıtlayın ve depo görünürlüğünü kimlerin değiştirebileceğini sınırlayın. Ayrıcalıklı kullanıcıların kısıtlamaları atlama izinlerini inceleyin. Kişisel hesapları, kod parçacıklarını, harici kuruluşları ve token erişimini ayrıca kontrol edin: kuruluş ayarları her hedefi yönetmez.

İlgili depoda değişikliklerin incelenmesini zorunlu kılın; dal korumasını ve kısıtlamaları atlama izinlerini inceleyin.

Kuruluşunuzun DLP konsolunda, hassas kaynak kodu içeriği ve DLP ürününüzün gerçekten kapsadığı yükleme veya depo kanalları için bir pilot ilke yapılandırın; eylemi engelleme olarak ayarlayın ve etkisiz, sentetik bir işaretleyiciyle test edin.

Kaynak kontrol platformu sunucu tarafı denetimleri destekliyorsa, gönderim alan depolar için incelenmiş kancaları yapılandırın ve zorunlu kılın.

Yetkili test hedeflerini kullanın ve herhangi bir yayımlama gerçekleşmeden önce engellemenin çalıştığını doğrulayın.

Doğrulayın

• Zararsız test dosyaları oluşturun ve erişimi reddedilen dosyaları okuma girişimlerinin başarısız olduğunu doğrulayın.

• Ağ erişimi etkinse onaylı bir hedefe erişimin başarılı olduğunu ve onaylanmamış bir hedefin engellendiğini kontrol edin; aksi takdirde ağ isteklerinin engellendiğini doğrulayın.

• Zararsız bir işaretleyici ve geçici test hesapları veya hedefleri kullanarak, temsili herkese açık yayımlama girişimlerinin yayımlama gerçekleşmeden önce engellendiğini doğrulayın.

Sınırlar

İzin verilen bir alan adı yine de herkese açık içerik barındırabilir. Web aramasını, uygulamaları, MCP server'ları, tarayıcı etkinliğini ve Codex Cloud'u ayrı olarak yapılandırın; yerel korumalı alan kuralları bunları denetlemez.

Şu yapılandırma tariflerini kullanır: İzin profillerini ve Full Access'i kısıtlayın; Yalnızca onaylı MCP server'lara izin verin; Ağ hedeflerini kısıtlayın; Gizli bilgileri ve ilgisiz depoları koruyun; Hassas komutlar için onay gerektirin.

Codex bir depoda çalışırken veya bir kullanıcı yerel yapılandırmaları değiştirirken, Codex'i yöneten kısıtlamaların yürürlükte kalmasını istiyorsunuz.

• Desteklenen izin, onay, MCP, ağ ve komut kısıtlamalarını yönetici tarafından zorunlu kılınan gereksinimler olarak dağıtın.

• Kanca betiklerini yönetici tarafından yönetilen bir dizine yükleyin ve kullanıcı, proje ve eklenti kancalarının yok sayılması gerekiyorsa yalnızca yönetilen kancaları kullanın.

• İlke dosyalarını ve yapılandırmanın dağıtım yolunu işletim sistemi ve cihaz yönetimi denetimleriyle koruyun. Codex'i bu korumaları değiştirmek için gereken ayrıcalıklar olmadan çalıştırın.

• Kapsamdaki her istemci ve ortam için geçerli yapılandırmayı inceleyin.

İzin verilen profilleri, onayları, sunucu kimliklerini ve komutları zorunlu kılın

Kullanıcının veya deponun düzenlenebilir ayarlarına güvenmek yerine, incelenmiş ayarları yönetici tarafından yönetilen requirements.toml dosyasına birleştirin. Örneğin:

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." },
]

Bu örnek iki profile izin verir, onay gerektiğinde insan incelemesini zorunlu kılar, eşleşen bir MCP kimliğine izin verir ve belirli bir komut öneki için onay ister.

MCP server'ın kendisini ayrı olarak yapılandırın ve kuruluşun diğer hassas komut örüntülerini ekleyin. Gerektiğinde genel dosya kısıtlamaları ve ağ kısıtlamaları ekleyin; gereksinimler desteklenen ayarları sınırlar ancak Codex dışındaki kimlik, hizmet ve hedef denetimlerinin yerini alamaz.

Yönetilen profil izin listeleri için Codex 0.138.0 veya üzeri gerekir.

Bir pilot istemcide izin verilmeyen bir profili seçmeyi, kısıtlanmış bir kullanıcı veya proje ayarını değiştirmeyi ve izin listesinde olmayan bir MCP kimliğini kullanmayı deneyin; her birinin reddedildiğini veya yeniden başlatma sonrasında kısıtlı kalmaya devam ettiğini doğrulayın. Bir test komutunun onayını reddedin ve komutun çalışmadığını doğrulayın.

Yönetilen dosya sistemi ve ağ kısıtlamaları ekleyin

İzin verilen profillerin tümünde hassas yerel dosyalara erişimi reddetmek için aşağıdaki tabloyu requirements.toml dosyasına ekleyin ve örnekleri kuruluşunuzun yollarıyla değiştirin:

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

Korumalı alandaki yerel komutların ağ erişimine ihtiyaç duyduğu durumlarda, izin verilen ve ağ erişimi etkin bir profili yönetilen hedeflerle birlikte tanımlayın:

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"

Önceki :workspace varsayılanının yerine bu profil ilkesini seçin veya her iki profil adını bilinçli olarak birleştirin; yinelenen anahtarlar veya tablolar yapıştırmayın. Komutların ağa ihtiyacı yoksa ağ erişimini devre dışı bırakın.

Erişimi reddedilen tam yolları zararsız dosyalar kullanarak doğrulayın; onaylı ve onaylanmamış hedefleri de doğrulayın.

Yerel Windows ortamında dosya erişim denetim listelerini de kullanın; çünkü kabuk alt süreçlerinin okuma işlemleri yalnızca yönetilen deny_read ile kapsanmaz.

Yerel komutların ağ ayarları diğer istemcileri, uygulamaları, bağlayıcıları veya bulutta yürütmeyi yönetmez.

Yönetici tarafından yönetilen kancaları yükleyin ve zorunlu kılın

Bir yöneticinin, incelenmiş bir kanca programını /etc/codex/hooks/pre_tool_use_policy.py gibi root tarafından yönetilen bir dizine yüklemesini sağlayın ve Codex kullanıcısının dosyayı veya dizinini değiştirmesini engelleyin. requirements.toml dosyasında kancaları etkinleştirin ve kullanıcı, proje, oturum ve eklenti kancalarını yok sayın:

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"

Bu gereksinim kancayı kaydeder ancak yüklemez. Yerel bir macOS entegrasyon testi için aşağıdakini pre_tool_use_policy.py olarak kaydedin ve bir yöneticinin aşağıdaki komutlarla yüklemesini sağlayın.

Bu yalnızca sentetik işaretleyiciyi engeller; buna güvenmeden önce kuruluşunuza özgü, incelenmiş bir ilkeyle değiştirin. Hedefte /usr/bin/python3 bulunduğunu doğrulayın ve gerekirse yorumlayıcı yolunu ayarlayın:

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

Yerel istemciyi yeniden başlatın, ardından:

• Zararsız bir Bash komutunun çalıştığını doğrulayın.

• CODEX_HOOK_TEST_DENY içeren bir komutun engellendiğini doğrulayın.

• İlkenin ve bağımlılıklarının Codex kullanıcısı tarafından değiştirilemediğini doğrulayın.

allow_managed_hooks_only, yönetilmeyen tüm kullanıcı, proje, oturum ve eklenti kancalarını atlar ve diğer iş akışlarını etkileyebilir.

Bash eşleştiricisi her aracı veya mevcut bir sürece daha sonra sağlanan her girdiyi kapsamaz; hatalar, zaman aşımları veya hatalı biçimlendirilmiş kanca yanıtları bir araç çağrısının devam etmesine izin verebilir.

Bulutta orkestre edilen Work, desteklenen farklı kanca işleyicileri kullanır. Bağımsız işletim sistemi ve hizmet korumalarını sürdürün. Bkz. Yönetilen kancalar ve kanca davranışı.

İlkeyi ve dağıtımını koruyun

macOS'te bir yönetici, incelenmiş ve birleştirilmiş bir gereksinim dosyasını root'a ait bir üst dizine dağıtabilir ve Codex kullanıcısının dosyaya yazmasını engelleyebilir:

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'ta uygun yönetici grubunu kullanın; Windows'ta ProgramData dizinini ve dosyayı yönetici tarafından yönetilen erişim denetim listeleriyle koruyun. MDM veya bulut ilkesini kimlerin değiştirebileceğini kısıtlayın, değişiklikleri inceleyin ve geri alma için bir kopya saklayın.

Yönetici olmayan bir pilot hesap kullanarak, hesabın ilkeyi, üst dizini veya yönetilen kanca programını değiştiremediğini doğrulayın; daha zayıf bir kullanıcı veya proje ayarını deneyin, Codex'i yeniden başlatın ve zorunlu kılınan davranışın sürdüğünü doğrulayın.

Tüm istemcilerin aynı ilkeyi yüklediğini varsaymak yerine kapsamdaki her istemciyi ve ortamı test edin.

Doğrulayın

Yönetici olmayan bir test kimliği kullanarak:

• Yönetilen ilkeyi düzenlemeyi deneyin. Beklenen: Yönetilen dosya değiştirilemez.

• Kullanıcı veya proje yapılandırması aracılığıyla bir kısıtlamayı zayıflatmayı deneyin. Beklenen: Daha zayıf ayarlar reddedilir veya kısıtlı kalır.

• İstemciyi yeniden başlatın ve kısıtlamaların hâlâ geçerli olduğunu doğrulayın.

Sınırlar

Ana makinede yeterli yönetici ayrıcalıklarına sahip bir kullanıcı veya ajan, çevredeki korumaları değiştirebilir. Kullanıcı tarafından düzenlenebilen ayarlar tek başına yönetici tarafından yönetilen gereksinimlerin yerini tutmaz.