Panduan praktis keamanan Codex

Gunakan panduan ini jika karyawan harus masuk ke Codex melalui ruang kerja ChatGPT perusahaan Anda, sementara akun ChatGPT pribadi dan autentikasi dengan API key dilarang pada endpoint terkelola.

Hasil yang diharapkan

Pada perangkat yang dikelola perusahaan, Codex hanya menerima proses masuk ChatGPT ke ruang kerja ChatGPT perusahaan.

Prasyarat

• UUID ruang kerja ChatGPT Enterprise yang disetujui.

• Cara untuk mendistribusikan konfigurasi terkelola Codex ke endpoint.

• Keputusan untuk melarang autentikasi dengan API key pada endpoint terkelola.

Konfigurasikan

1. Catat UUID ruang kerja yang disetujui dalam repositori konfigurasi internal Anda.

2. Tambahkan persyaratan autentikasi yang diberlakukan ke requirements.toml lokal:

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

Kunci pertama hanya mengizinkan autentikasi ChatGPT; kunci kedua membatasi proses masuk ke ruang kerja yang disetujui. Ganti UUID ilustrasi dengan UUID ruang kerja Anda. Lihat referensi persyaratan.

3. Terapkan melalui requirements.toml lokal atau persyaratan MDM macOS menggunakan jalur dalam Tempat konfigurasi diterapkan. Persyaratan autentikasi ini berlaku sebelum kredensial dimuat dan sebelum kebijakan cloud diambil; Codex mengabaikannya dalam persyaratan yang dikelola cloud. Lindungi file dan direktori induknya agar tidak dapat diubah pengguna. Nilai default managed_config.toml lama tidak memberlakukan pembatasan ini.

4. Selama uji coba, keluarkan pengguna dari akun mereka atau hapus sesi Codex pribadi yang sebelumnya disimpan. Jangan berasumsi bahwa kebijakan baru secara retroaktif membatalkan sesi yang sudah ada.

5. Padukan pembatasan masuk dengan peran ruang kerja dan akses grup. Autentikasi mengontrol identitas yang masuk; RBAC mengontrol fitur Codex yang boleh digunakan identitas tersebut. Lihat Autentikasi.

Verifikasi

• Keluar dari Codex.

• Coba masuk dengan akun ChatGPT pribadi. Hasil yang diharapkan: Proses masuk ke ruang kerja pribadi ditolak.

• Coba masuk ke Codex dengan API key. Hasil yang diharapkan: Proses masuk dengan API key ditolak.

• Masuk ke ruang kerja yang disetujui dengan akun perusahaan. Hasil yang diharapkan: Proses masuk berhasil.

• Mulai ulang aplikasi desktop, CLI, dan ekstensi IDE, lalu ulangi.

Pulihkan konfigurasi

Pulihkan persyaratan autentikasi lokal sebelumnya dan terapkan kembali paket yang telah ditinjau.

Batasan

Kontrol ini berlaku untuk klien Codex terkelola pada endpoint terkelola. Padukan dengan kontrol aplikasi endpoint dan kebijakan jaringan jika persyaratannya adalah “tidak boleh ada penggunaan Codex pribadi dari aset perusahaan.”

Gunakan panduan ini jika pengembang memerlukan akses hanya baca atau akses terbatas pada ruang kerja, dan Anda ingin mencegah mereka memilih Akses Penuh atau melewati persetujuan dan sandbox dengan --yolo.

Hasil yang diharapkan

Pengguna hanya dapat memilih profil hanya baca atau profil terbatas pada ruang kerja yang disetujui. Mereka tidak dapat memilih danger-full-access, approval_policy = "never", atau --yolo.

Konfigurasikan

1. Tentukan profil ruang kerja yang disetujui:

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

2. Berlakukan profil dan kebijakan persetujuan yang diizinkan:

   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

Daftar izin ini bersifat menyeluruh: profil yang tidak tercantum dalam daftar izin atau disetel ke false ditolak, termasuk profil yang ditambahkan pada versi mendatang. Lihat Referensi Konfigurasi.

3. Untuk klien lama yang masih menggunakan sandbox_mode, gunakan:

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

4. Distribusikan ini sebagai persyaratan yang diberlakukan administrator, bukan file konfigurasi yang dapat diedit pengguna.

5. Jika nantinya Anda mengizinkan Tinjauan otomatis, tambahkan secara sengaja setelah pengujian. Tinjauan otomatis mengubah pihak yang meninjau tindakan yang melampaui batas; fitur ini tidak memulihkan batas yang telah dihapus. Lihat Tinjauan otomatis.

Verifikasi

• Buka pemilih izin. Hasil yang diharapkan: Akses Penuh tidak tersedia atau ditolak.

• Jalankan dengan --dangerously-bypass-approvals-and-sandbox. Hasil yang diharapkan: Codex menolak peluncuran atau memaksakan profil yang kompatibel.

• Jalankan dengan --sandbox danger-full-access --ask-for-approval never. Hasil yang diharapkan: Peluncuran ditolak.

• Jalankan tugas ruang kerja biasa. Hasil yang diharapkan: Tugas berhasil; tindakan yang melampaui batas tetap memerlukan persetujuan.

Pulihkan konfigurasi

Pulihkan paket persyaratan sebelumnya. Tetap blokir akses tanpa batas kecuali ada pengecualian yang disetujui secara terpisah.

Batasan

Kontrol ini mengatur izin runtime Codex. Kontrol ini tidak menghilangkan hak istimewa akun sistem operasi yang memilikinya.

Gunakan panduan ini jika organisasi Anda perlu menentukan MCP server yang boleh digunakan Codex dan memberlakukan daftar yang disetujui.

Mengizinkan server dan mengonfigurasinya merupakan langkah terpisah. Entri daftar izin mengizinkan server yang cocok; entri tersebut tidak membuat konfigurasi server. Konfigurasikan server secara terpisah dengan nama dan identitas yang cocok, beserta autentikasi yang diperlukannya.

Hasil yang diharapkan

Codex hanya mengaktifkan MCP server yang nama dan identitas konfigurasinya cocok dengan daftar yang disetujui perusahaan.

Konfigurasikan

1. Inventarisasikan setiap server yang disetujui: pemilik, tujuan, transport, executable atau URL yang persis, autentikasi, klasifikasi data, dan alat yang memiliki kemampuan menulis.

2. Mulai dengan menolak semuanya. Tabel terkelola yang kosong menonaktifkan semua MCP server:

   [mcp_servers]

3. Tambahkan server HTTP yang disetujui berdasarkan URL yang persis:

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

4. Tambahkan server stdio yang disetujui berdasarkan executable dan argumen posisional:

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

Pencocok terstruktur memeriksa executable, jumlah argumen, dan urutan argumen. Pencocok ini tidak membatasi cwd, env, atau env_vars. Jadikan kontrol atas seluruh konteks peluncuran sebagai prasyarat untuk menyetujui server stdio: lindungi executable dan dependensinya, serta cegah konfigurasi pengguna atau proyek yang tidak tepercaya memasok direktori kerja atau lingkungan yang dapat mengubah perilakunya. Jika Anda tidak dapat memberlakukan batas tersebut secara independen, jangan setujui server stdio dan gunakan server HTTP yang telah ditinjau sebagai gantinya.

5. Tambahkan identitas MCP yang disertakan dalam plugin secara terpisah di bawah plugins.<plugin>.mcp_servers.<server>.

6. Simpan daftar yang disetujui dalam repositori konfigurasi yang telah ditinjau dan terapkan melalui persyaratan yang diberlakukan administrator.

Klien hanya mengaktifkan server jika nama dan identitasnya sama-sama cocok dengan entri yang disetujui. Lihat Konfigurasi terkelola.

Verifikasi

• Konfigurasikan server yang disetujui secara persis. Hasil yang diharapkan: Server berjalan.

• Ubah satu karakter URL. Hasil yang diharapkan: Server dinonaktifkan.

• Ubah jumlah atau urutan argumen stdio, atau berikan argumen di luar aturan argumen yang dikonfigurasi. Hasil yang diharapkan: Server dinonaktifkan. Nilai yang masih memenuhi prefiks yang diizinkan tetap diperbolehkan.

• Dalam proyek tepercaya yang dapat dibuang setelah pengujian, coba penggantian cwd, env, dan env_vars yang tidak berbahaya sambil mempertahankan executable dan argumen yang cocok. Pencocokan identitas saja tidak menolak penggantian ini. Pastikan kontrol konteks peluncuran independen Anda menolak penggantian yang tidak aman atau server stdio tetap tidak disetujui; jangan gunakan payload injeksi sungguhan.

• Tambahkan nama yang tidak disetujui. Hasil yang diharapkan: Server dinonaktifkan.

• Uji server yang disertakan dalam plugin. Hasil yang diharapkan: Server hanya berfungsi dengan identitas yang disetujui.

Pulihkan konfigurasi

Hapus entri yang baru ditambahkan. Untuk segera menghentikan semua penggunaan MCP, terapkan tabel mcp_servers yang kosong.

Batasan

Pencantuman identitas dalam daftar izin tidak membuktikan bahwa alat, data hulu, kredensial, atau lingkungan peluncuran server aman. Proses MCP stdio lokal berjalan di luar sandbox perintah lokal; mencocokkan executable dan argumen tidak membatasi akses server atau mencegah pemuatan kode berbasis lingkungan. Tinjau seluruh konteks peluncuran dan izin server secara independen. Lihat Persyaratan identitas MCP.

Gunakan panduan ini jika tim keamanan Anda perlu memahami aktivitas Codex pada endpoint dan dalam jaringan Anda. Panduan ini menggabungkan peristiwa eksekusi dan alat, keputusan persetujuan, catatan audit ruang kerja, dan log jaringan untuk investigasi.

Hasil yang diharapkan

Tim keamanan dapat mengorelasikan eksekusi Codex, keputusan alat, persetujuan, catatan audit ruang kerja, dan lalu lintas jaringan keluar yang sebenarnya tanpa bergantung pada narasi model itu sendiri.

Gunakan empat sumber bukti

1. OpenTelemetry Codex: peristiwa eksekusi, API, model, sandbox, persetujuan, dan alat.

2. Hook siklus hidup terkelola: catatan di sisi endpoint seputar penggunaan alat dan permintaan izin.

3. Log proxy atau gateway jaringan: tujuan DNS/HTTP yang sebenarnya dan hasil koneksi.

4. Compliance API: catatan audit dan investigasi tingkat ruang kerja.

Tidak ada satu sumber pun yang menyediakan pemantauan jaringan lengkap.

Konfigurasikan

1. Kirim log OpenTelemetry Codex ke kolektor Anda, dengan prompt mentah disamarkan:

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

Sediakan OTLP_TOKEN untuk proses Codex melalui pengelola rahasia yang disetujui atau lingkungan proses sebelum memulai klien. Jangan sertakan token dalam file TOML yang diterapkan maupun kontrol sumber.

Codex dapat menghasilkan peristiwa awal percakapan, permintaan API, peristiwa streaming, metadata prompt, keputusan alat, dan hasil alat. Lihat Konfigurasi Lanjutan.

2. Terapkan OTel di luar konfigurasi lokal proyek. File .codex/config.toml proyek tidak dapat mengganti perutean telemetri.

3. Tambahkan hook siklus hidup terkelola untuk SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop, dan SessionEnd.

4. Instal skrip hook dalam direktori yang dikelola administrator dan atur allow_managed_hooks_only = true jika hook pengguna, proyek, dan plugin harus diabaikan.

5. Rutekan lalu lintas perintah dalam sandbox melalui proxy dengan pencatatan log independen. OTel mencatat bahwa alat dijalankan; proxy mencatat tujuan yang dicoba dihubungi subproses.

6. Konfigurasikan telemetri terpisah untuk pencarian web, aplikasi, konektor, MCP server, aktivitas browser, dan Codex Cloud. Aturan proxy perintah lokal tidak otomatis mencakup semuanya.

7. Alirkan catatan Compliance API yang didukung ke SIEM dan terapkan kontrol retensi serta penahanan data untuk keperluan hukum Anda sendiri. Lihat Compliance API dan peristiwa audit.

8. Korelasikan pengguna atau akun layanan, host atau runner, ID percakapan, model, versi klien, profil izin, keputusan persetujuan, tujuan, dan nama alat.

Verifikasi

Jalankan sesi terkendali yang melakukan hal berikut:

• Membaca satu file yang diizinkan.

• Mencoba membaca satu file yang diblokir.

• Menjalankan satu perintah yang diizinkan.

• Mencoba satu permintaan keluar yang diblokir.

• Meminta persetujuan dan menerima penolakan.

• Mengakhiri sesi.

Hasil yang diharapkan berdasarkan sumber bukti:

• OTel menampilkan peristiwa eksekusi dan alat.

• Hook menampilkan siklus hidup sesi.

• Log proxy menampilkan tujuan yang diizinkan dan diblokir.

• Proses pemasukan data Compliance menerima catatan yang didukung.

• SIEM mengorelasikan catatan tersebut dengan pengguna atau beban kerja.

Pulihkan konfigurasi

Nonaktifkan eksportir dan hook dengan memulihkan konfigurasi sebelumnya. Jangan hapus pencatatan log proxy independen sebagai bagian dari pemulihan konfigurasi telemetri.

Batasan

Jangan menjanjikan bahwa telemetri Codex merekam setiap argumen perintah, byte keluaran, atau paket jaringan. Dokumentasikan cakupan setiap lapisan.

Gunakan panduan ini jika Codex tidak boleh memiliki akses internet atau hanya boleh menjangkau tujuan yang disetujui. Pilih prosedur lokal atau cloud untuk lingkungan yang Anda konfigurasi, dan perhatikan bahwa cakupan kebijakan keduanya terpisah.

Hasil yang diharapkan

Codex tidak memiliki akses internet, atau hanya menjangkau domain yang disetujui, sesuai konfigurasi yang Anda pilih. Lingkungan Codex Cloud (Legacy) juga dapat membatasi metode HTTP.

Konfigurasikan Codex Cloud saat ini

1. Buat lingkungan terpisah untuk tingkat kepercayaan yang berbeda, seperti no-internet-review, approved-dependencies-build, dan cyber-lab.

2. Dalam konfigurasi lingkungan, biarkan Izinkan Codex mengakses internet nonaktif kecuali alur kerja memerlukan akses internet.

3. Jika akses diperlukan, aktifkan Izinkan Codex mengakses internet. Pada Izinkan domain, pilih Hanya domain kustom, lalu tambahkan host yang diperlukan secara persis pada Domain tambahan yang diizinkan.

4. Simpan dan uji layanan selama penyiapan. Publikasikan atau publikasikan ulang lingkungan, lalu uji akses ke tujuan yang disetujui dan tidak disetujui dalam tugas baru. Tinjau skrip penyiapan secara terpisah: tetapkan versi dependensi, utamakan mirror yang disetujui, dan hindari unduhan executable yang belum ditinjau.

Lihat Menghubungkan ke layanan. Pengaturan Codex Cloud saat ini tidak menyediakan pemilih metode HTTP Legacy.

Konfigurasikan Codex Cloud (Legacy)

1. Biarkan akses internet agen Nonaktif jika tidak diperlukan. Legacy Cloud memblokir internet selama fase agen secara default; skrip penyiapan tetap berjalan dengan akses internet untuk instalasi dependensi.

2. Jika akses agen diperlukan, Aktifkan dengan daftar izin yang terbatas. Mulai dengan Tidak ada dan tambahkan domain secara persis.

3. Untuk alur kerja khusus unduhan, izinkan hanya GET, HEAD, dan OPTIONS. Ini memblokir POST, PUT, PATCH, DELETE, dan metode lainnya. Tinjau skrip penyiapan secara terpisah karena pembatasan fase agen tidak mengatur akses internetnya.

Lihat Akses internet agen Legacy. Preset dan kontrol metode HTTP ini hanya berlaku untuk Legacy Cloud.

Konfigurasikan Codex lokal

1. Dalam requirements.toml yang dikelola administrator, tentukan dan pilih profil jaringan yang disetujui, serta batasi pengguna hanya pada profil tersebut:

   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. Terapkan paket persyaratan yang telah ditinjau menggunakan Konfigurasi terkelola. Profil bernama saja belum aktif; default_permissions memilihnya, dan daftar izin mencegah pemilihan profil lain.

3. Aktifkan proxy yang dikelola administrator dalam paket persyaratan yang sama agar pembatasan domain diberlakukan dan pengguna tidak dapat memperluasnya. Terapkan proxy dan profil dengan jaringan aktif secara bersamaan; profil dengan jaringan aktif tanpa proxy aktif memberikan akses jaringan langsung tanpa memberlakukan aturan domainnya:

   Perhatian: [experimental_network] bersifat eksperimental dan dapat berubah. Validasi pada setiap versi klien lokal dan sistem operasi yang didukung sebelum penerapan lebih luas. Dukungan Windows terbatas; jangan terapkan kebijakan ini kepada pengguna Windows sebelum Anda menguji pemberlakuannya di lingkungan Anda.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

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

4. Biarkan pengikatan port lokal nonaktif kecuali alur kerja memerlukannya. Konfigurasikan akses ke target jaringan privat secara terpisah; mengizinkan domain saja tidak berarti menyetujui alamat privatnya. Lihat Persyaratan akses jaringan.

5. Konfigurasikan pencarian web, aplikasi, MCP server, aktivitas browser, dan Codex Cloud secara terpisah. Aturan sandbox lokal tidak mengontrol semuanya.

Verifikasi

• Kirim permintaan ke domain yang disetujui dan pastikan permintaan berhasil.

• Kirim permintaan ke domain yang tidak disetujui dan pastikan permintaan diblokir.

• Kirim permintaan ke localhost, IP privat, dan endpoint metadata cloud. Pastikan setiap permintaan diblokir kecuali disetujui secara eksplisit.

• Di Codex Cloud (Legacy), coba permintaan POST ke domain yang diizinkan. Pastikan permintaan diblokir ketika hanya GET, HEAD, dan OPTIONS yang diizinkan.

• Pastikan log proxy atau gateway memuat entri untuk permintaan yang diizinkan maupun ditolak.

Pulihkan konfigurasi

Kembalikan lingkungan ke Nonaktif atau pulihkan kebijakan domain sebelumnya. Hindari pemulihan ke akses internet tanpa batas.

Batasan

Eskalasi sandbox penuh yang disetujui dapat melewati proxy perintah lokal. Uji perintah biasa dalam sandbox dan perintah dengan eskalasi yang disetujui secara terpisah sebelum mengandalkan pembatasan ini.

Domain yang diizinkan tetap dapat menghosting injeksi prompt, paket yang disusupi, atau dokumentasi yang tidak aman.

Gunakan panduan ini jika Codex memerlukan akses ke direktori sumber yang disetujui, sementara rahasia, file .env, kunci SSH, dan repositori yang tidak terkait harus tetap tidak terjangkau. Panduan ini mencakup pembatasan akses file dan pengurangan jumlah variabel lingkungan yang memuat kredensial yang diteruskan ke perintah yang dijalankan sebagai proses baru.

Hasil yang diharapkan

Codex dapat bekerja dalam direktori sumber yang disetujui, tetapi tidak dapat membaca file umum yang memuat rahasia atau mewarisi sekumpulan besar variabel lingkungan yang memuat kredensial.

Konfigurasikan

1. Tentukan pola penolakan baca dalam profil ruang kerja:

   [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. Tambahkan jalur penolakan yang persis untuk direktori kredensial yang diketahui, kunci penandatanganan, konfigurasi produksi, dan repositori di sekitarnya.

3. Dalam /etc/codex/config.toml sistem atau ~/.codex/config.toml pengguna, kurangi variabel lingkungan yang diteruskan ke perintah yang dijalankan sebagai proses baru:

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

Ini merupakan nilai default yang dapat dikonfigurasi pengguna, bukan persyaratan yang diberlakukan. Pengaturan ini mengurangi variabel yang diwarisi, tetapi tidak mencegah akses ke file kredensial, helper, konten startup shell, atau identitas lain. Lihat Konfigurasi Lanjutan.

4. Dalam requirements.toml yang dikelola administrator, pilih profil terbatas dan izinkan hanya profil tersebut. Profil bawaan tidak mewarisi penolakan file rahasianya:

   default_permissions = "corp-workspace"

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

5. Pilih alur kredensial untuk lingkungan Cloud Anda:

   • Di Codex Cloud saat ini, gunakan Rahasia jaringan untuk kredensial yang dikirim ke layanan HTTPS yang diizinkan. Program menerima placeholder, dan proxy menggantinya dengan nilai sebenarnya untuk tujuan yang disetujui pada port 443 selama penyiapan dan tugas. Kredensial mentah tidak ditempatkan dalam proses atau file lokal. Variabel lingkungan langsung tersedia bagi program. Lihat Variabel lingkungan dan rahasia jaringan.
   • Di Codex Cloud (Legacy), rahasia mendukung autentikasi saat penyiapan dan dihapus sebelum fase agen; variabel lingkungan tetap tersedia sepanjang percakapan. Lihat Lingkungan Legacy Cloud.

6. Jika agen memerlukan autentikasi, gunakan perantara independen untuk menyediakan kredensial berumur pendek dengan cakupan terbatas pada target dan tindakan yang tepat. Lihat Konfigurasi yang direkomendasikan.

Verifikasi

Buat file umpan pengujian yang tidak berbahaya:

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

Lalu minta Codex untuk:

• Membaca file biasa.

• Membaca setiap file umpan.

• Mencari rahasia secara rekursif.

• Mencetak lingkungan perintahnya.

• Membaca repositori di sekitarnya.

Hasil yang diharapkan: Pembacaan file biasa berhasil; file yang ditolak dan repositori di sekitarnya tetap tidak dapat diakses, dan variabel yang dikecualikan tidak ada dalam lingkungan perintah.

Pulihkan konfigurasi

Pulihkan profil sebelumnya, tetapi pertahankan penolakan file rahasia yang tingkat kepastiannya tinggi selama menyelidiki kegagalan alur kerja.

Batasan

Penolakan sistem file tidak menghapus rahasia yang sudah ditempelkan ke prompt, di-commit ke sumber yang dapat dibaca, dikembalikan oleh konektor, atau ditulis ke log yang dapat diakses model.

Gunakan panduan ini jika tindakan seperti git push, penerapan, migrasi database, dan perintah CLI cloud memerlukan persetujuan sebelum dijalankan. Tentukan perintah yang harus meminta peninjauan dan yang harus dilarang, lalu konfigurasikan aturan untuk perintah tersebut.

Hasil yang diharapkan

Perintah sensitif selalu dijeda untuk persetujuan atau dilarang, bahkan ketika model menganggapnya sesuai.

Konfigurasikan

1. Tentukan perintah yang memerlukan permintaan persetujuan dan yang dilarang.

2. Tambahkan aturan perintah yang diberlakukan administrator:

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

Aturan persyaratan dapat mewajibkan permintaan persetujuan atau melarang perintah; aturan tersebut tidak dapat mengizinkannya. Lihat Konfigurasi terkelola.

3. Untuk profil berisiko tinggi, tambahkan entri pembungkus shell ke array prefix_rules yang sama jika pembungkus dapat menyamarkan perintah sensitif:

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

Entri pembungkus shell menghasilkan banyak permintaan persetujuan; gunakan secara selektif.

4. Jika seseorang harus menyetujui perintah, berlakukan pengaturan berikut:

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

Tinjauan otomatis mengubah peninjau; fitur ini bukan jaminan keamanan deterministik. Lihat Tinjauan otomatis.

5. Kirim peristiwa PermissionRequest, keputusan alat, dan hasil alat ke pipeline keamanan.

Verifikasi

• Jalankan git status. Hasil yang diharapkan: Tidak muncul permintaan persetujuan.

• Jalankan git push. Hasil yang diharapkan: Muncul permintaan persetujuan.

• Jalankan terraform apply. Hasil yang diharapkan: Muncul permintaan persetujuan.

• Jalankan kubectl delete pod test. Hasil yang diharapkan: Muncul permintaan persetujuan.

• Jalankan rm -rf test-directory. Hasil yang diharapkan: Perintah dilarang.

• Tolak satu permintaan persetujuan. Hasil yang diharapkan: Perintah tidak dijalankan, dan penolakan dicatat dalam log.

• Mulai ulang klien dan ulangi pemeriksaan. Hasil yang diharapkan: Aturan tetap diberlakukan.

Pulihkan konfigurasi

Pulihkan paket persyaratan sebelumnya. Persempit pola token yang terlalu luas alih-alih menghapus seluruh kelas perintah sensitif.

Batasan

Aturan prefiks bukan mesin kebijakan sistem operasi yang lengkap. Padukan dengan sandbox, akun OS dengan hak istimewa minimum, pembatasan jaringan, IAM cloud, perlindungan cabang, persetujuan penerapan, dan otorisasi database.

Menggunakan panduan konfigurasi berikut: Membatasi profil izin dan Akses Penuh; Melindungi rahasia dan repositori yang tidak terkait; Mewajibkan persetujuan untuk perintah sensitif.

Pengembang memiliki akses produksi yang sah, tetapi Anda ingin Codex membantu pengembangan tanpa membuat perubahan produksi yang belum ditinjau.

• Tentukan profil ruang kerja yang disetujui dan berlakukan profil serta kebijakan persetujuan yang diizinkan. Distribusikan pengaturan ini sebagai persyaratan yang diberlakukan administrator untuk mencegah pengguna menggantinya.

• Jalankan Codex dengan identitas terpisah yang memiliki hak istimewa lebih rendah atau dalam lingkungan yang tidak dapat mengakses atau memperoleh kredensial tulis produksi. Pengembang dapat mempertahankan akses produksi melalui alur kerja resmi yang terpisah.

• Minimalkan variabel lingkungan yang diteruskan ke perintah yang dijalankan sebagai proses baru. Jika agen memerlukan autentikasi, gunakan perantara independen untuk menyediakan kredensial berumur pendek dengan cakupan terbatas pada target dan tindakan yang tepat.

• Tentukan perintah yang memerlukan permintaan persetujuan dan yang dilarang. Wajibkan seseorang menyetujui perintah tertentu yang berdampak besar, seperti git push, terraform apply, perubahan Kubernetes, dan migrasi database; larang perintah yang tidak boleh dijalankan sama sekali.

• Tetap berlakukan IAM produksi, perlindungan cabang, dan persetujuan penerapan secara independen dari Codex.

Batasi profil izin dan wajibkan peninjau manusia

Dalam requirements.toml yang dikelola administrator, izinkan profil ruang kerja dan hanya baca bawaan serta wajibkan peninjauan pengguna untuk tindakan yang memerlukan persetujuan:

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

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

Profil ruang kerja mengizinkan pekerjaan dalam ruang kerja di dalam sandbox-nya; profil hanya baca tersedia untuk pekerjaan dengan cakupan lebih sempit. Profil akses penuh tidak tercantum dalam daftar izin.

Atur approval_policy = "on-request" dalam konfigurasi klien jika klien memerlukan pilihan kompatibel yang eksplisit. on-request mengizinkan permintaan persetujuan saat diperlukan; pengaturan ini tidak meminta persetujuan untuk setiap perintah. Tambahkan aturan eksplisit untuk tindakan yang memerlukan peninjauan, dan pertahankan otorisasi produksi independen.

Daftar izin profil terkelola memerlukan Codex 0.138.0 atau yang lebih baru; gunakan dan uji persyaratan mode sandbox lama yang didokumentasikan untuk klien yang lebih lama.

Mulai ulang setiap klien uji coba, pastikan profil yang disetujui berfungsi, dan pastikan profil akses penuh yang tidak diizinkan ditolak.

Pisahkan identitas Codex dari kredensial produksi

Dalam sistem pengelolaan perangkat atau penyediaan lingkungan pengembangan Anda, buat pengguna Codex, container, atau host pengembangan khusus dengan akses hanya ke sumber dan layanan pengembangan yang diperlukannya. Jangan pasang file kredensial produksi, helper token, atau keychain pengembang ke dalam lingkungan tersebut, dan cegah identitas itu memperoleh peran dengan akses tulis produksi.

Jika agen memerlukan akses layanan, konfigurasikan perantara kredensial organisasi Anda untuk menerbitkan kredensial berumur pendek yang dibatasi pada sumber daya dan tindakan pengembangan. Pengembang dapat menggunakan identitas normalnya melalui alur kerja produksi resmi yang terpisah.

Misalnya, di AWS IAM, buka Peran, pilih peran pengembangan Codex, lalu pada Izin tambahkan kebijakan inline yang telah ditinjau seperti berikut, dengan mengganti akun dan peran menggunakan milik Anda sendiri:

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

Contoh ini menolak upaya mengambil peran yang disebutkan, tetapi tidak menolak upaya mengambil peran lain. Hapus juga izin produksi langsung, batasi peran produksi dan sumber kredensial lainnya, serta tinjau kebijakan kepercayaan dan kontrol tingkat organisasi.

Uji peran pengembangan terhadap izin pengembangan dan produksi yang representatif tanpa membuat perubahan pada produksi. Lihat Contoh kebijakan peran AWS IAM.

Minimalkan lingkungan shell

Dalam /etc/codex/config.toml untuk konfigurasi awal seluruh sistem, atau ~/.codex/config.toml untuk satu pengguna, konfigurasikan variabel lingkungan yang diwarisi oleh perintah yang dijalankan:

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

Ini adalah pengaturan default yang dapat dikonfigurasi, bukan batas kredensial yang ditegakkan. Pengaturan pengguna, inisialisasi atau snapshot shell, helper kredensial, dan sumber kredensial lainnya masih dapat mengekspos kredensial.

Dalam requirements.toml, gunakan pembatasan opsional berikut untuk menonaktifkan shell login dan snapshot shell jika sesuai dengan alur kerja Anda:

allow_login_shell = false

[features]
shell_snapshot = false

Uji coba pengaturan ini karena beberapa alur kerja bergantung pada inisialisasi shell login.

Mulai Codex dengan variabel sintetis yang tidak berbahaya dan sesuai dengan filter, lalu periksa lingkungan perintah yang dijalankan; verifikasi juga bahwa permintaan shell login ditolak jika dinonaktifkan. Verifikasi secara terpisah bahwa identitas eksekusi tidak dapat mengakses kredensial produksi yang sebenarnya. Lihat Kebijakan lingkungan shell.

Minta persetujuan untuk perintah tertentu yang berdampak besar

Tambahkan aturan persyaratan untuk perintah yang digunakan organisasi Anda. Misalnya:

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

Gunakan forbidden untuk perintah yang sama sekali tidak boleh dijalankan; ganti atau tambahkan pola untuk alat deployment dan migrasi yang sebenarnya.

Aturan ini mencocokkan awalan perintah dan tidak mencakup setiap tindakan yang setara. Uji jalur absolut, wrapper, urutan argumen alternatif, klien lain, dan alat lain secara terpisah.

Pada target sekali pakai, jalankan perintah biasa, minta tindakan yang tercantum, tolak permintaan persetujuan, lalu verifikasi bahwa tindakan tersebut tidak dijalankan. Lihat Menegakkan aturan perintah.

Tegakkan persetujuan repositori dan deployment di luar Codex

Di platform kontrol sumber Anda, lindungi branch produksi seperti main: wajibkan perubahan yang telah ditinjau serta persetujuan dan pemeriksaan status yang diperlukan, lalu tinjau peran mana yang dapat melewati persyaratan tersebut. Konfigurasikan persetujuan deployment di sistem deployment terkait dan hak akses basis data di basis data itu sendiri.

Gunakan repositori sekali pakai untuk memverifikasi bahwa perubahan yang telah ditinjau berhasil dan push langsung tanpa otorisasi ditolak. Kontrol ini berlaku terlepas dari apakah tindakan diminta melalui Codex.

Verifikasi

Pada target pengujian sekali pakai:

• Jalankan tugas ruang kerja biasa. Hasil yang diharapkan: Tugas berhasil.

• Coba perintah sensitif yang representatif dan tolak permintaan persetujuan. Hasil yang diharapkan: Perintah yang ditolak tidak dijalankan.

• Verifikasi bahwa identitas Codex tidak dapat memperoleh akses tulis ke produksi.

• Mulai ulang klien dan ulangi.

Batasan

Aturan awalan bukan mesin kebijakan sistem operasi yang lengkap. Padukan dengan sandbox, akun OS dengan hak akses minimum, pembatasan jaringan, IAM cloud, perlindungan branch, persetujuan deployment, dan otorisasi basis data.

Menggunakan panduan konfigurasi berikut: Lindungi rahasia dan repositori yang tidak terkait; Batasi tujuan jaringan; Izinkan hanya MCP server yang disetujui; Wajibkan persetujuan untuk perintah sensitif.

Pengembang menggunakan Codex dengan repositori internal, dan Anda ingin mengurangi risiko kode dikirim ke repositori publik, cuplikan kode publik, atau tujuan lain yang tidak disetujui.

• Tambahkan jalur penolakan yang spesifik untuk direktori kredensial dan repositori tidak terkait yang diketahui, lalu minimalkan variabel lingkungan yang diteruskan ke perintah yang dijalankan.

• Jika akses internet agen diperlukan, gunakan daftar izin terbatas yang berisi domain yang disetujui. Izinkan hanya nama dan identitas MCP server yang disetujui, serta wajibkan peninjauan untuk perintah publikasi tertentu atau tolak perintah tersebut, seperti git push.

• Gunakan hook dan izin kontrol sumber, kebijakan untuk repositori publik dan cuplikan kode, serta kontrol pencegahan kehilangan data yang sesuai untuk organisasi Anda.

Tolak akses ke repositori yang tidak terkait dan berkas kredensial

Dalam requirements.toml yang dikelola administrator, tambahkan jalur spesifik yang tidak boleh dibaca oleh agen lokal:

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

Ganti contoh dengan jalur yang ada di perangkat terkelola Anda. Penolakan terkelola ini berlaku di seluruh profil izin yang diizinkan; penolakan yang dikonfigurasi hanya di dalam satu profil khusus tidak melindungi pengguna yang memilih profil lain. Utamakan jalur spesifik yang diketahui dan uji setiap pola glob pada kedalaman direktori yang Anda perlukan.

Pada Windows native, deny_read terkelola mencakup alat berkas langsung, tetapi tidak dengan sendirinya mencegah pembacaan oleh subproses shell; gunakan juga identitas OS dan daftar kontrol akses berkas.

Buat berkas canary yang tidak berbahaya di lokasi yang ditolak. Pada setiap profil yang diizinkan, verifikasi bahwa pembacaan langsung maupun melalui shell terhadap berkas tersebut ditolak dan bahwa berkas sumber yang disetujui dapat dibaca. Lihat Persyaratan penolakan baca terkelola.

Minimalkan variabel shell yang memuat kredensial

Dalam /etc/codex/config.toml atau ~/.codex/config.toml, tetapkan lingkungan warisan yang terbatas:

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

Pengaturan ini mengurangi variabel yang diwarisi, tetapi dapat dikonfigurasi pengguna dan tidak mencegah akses ke berkas kredensial, helper, konten inisialisasi shell, atau identitas lain.

Jika sesuai, administrator juga dapat menambahkan pembatasan ini ke requirements.toml dan mengujicobakannya untuk menilai dampaknya pada alur kerja pengembang:

allow_login_shell = false

[features]
shell_snapshot = false

Uji dengan variabel canary sintetis dan identitas eksekusi terpisah dengan hak akses minimum. Jangan gunakan kredensial yang sebenarnya. Lihat Kebijakan lingkungan shell.

Izinkan hanya tujuan jaringan yang disetujui untuk perintah lokal

Jika perintah lokal dalam sandbox memerlukan akses jaringan, gabungkan pengaturan profil dan proksi terkelola di bawah ini ke dalam requirements.toml, lalu ganti domain dengan endpoint yang disetujui:

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"

Profil yang mengaktifkan jaringan memberikan jalur jaringan kepada perintah dalam sandbox, sedangkan proksi terkelola membatasi tujuannya. Terapkan keduanya secara bersamaan; profil yang mengaktifkan jaringan tanpa proksi terkelola yang dimaksud tidak menerapkan pembatasan tujuan yang sama. Jika akses internet tidak diperlukan, biarkan akses jaringan dinonaktifkan.

Jangan gabungkan tabel kanonis domains dengan pengaturan lama allowed_domains atau denied_domains; migrasikan dan uji kebijakan yang ada.

Mulai ulang klien dan verifikasi bahwa endpoint yang disetujui berfungsi dan endpoint yang tidak disetujui diblokir.

Pengaturan ini bersifat eksperimental; validasi dukungan OS dan klien, lalu konfigurasikan akses jaringan privat secara terpisah jika host yang disetujui diresolusikan ke alamat privat. Eskalasi sandbox penuh yang disetujui dapat melewati proksi perintah.

Kontrol jaringan untuk perintah lokal ini tidak dengan sendirinya mencakup pencarian web, aplikasi, MCP server, aktivitas browser, atau lingkungan cloud, yang memerlukan kebijakan terpisah. Domain hosting yang disetujui juga dapat memuat repositori publik atau cuplikan kode publik, sehingga daftar izin tujuan saja tidak melindungi konten. Lihat Persyaratan akses jaringan.

Konfigurasikan jaringan lingkungan cloud secara terpisah

Di antarmuka Codex Cloud saat ini, buka konfigurasi lingkungan. Biarkan Izinkan Codex mengakses internet nonaktif. Jika Anda memerlukan akses internet, aktifkan dan pilih Hanya domain khusus, tambahkan host spesifik yang diperlukan di bagian Domain tambahan yang diizinkan, lalu simpan konfigurasi, publikasikan atau publikasikan ulang lingkungan, dan uji tugas baru.

Tinjau autentikasi dan kemampuan layanan secara terpisah.

Codex Cloud versi lama menggunakan pengaturan internet agen terpisah untuk setiap lingkungan dengan kontrol domain dan metode HTTP yang diizinkan; skrip penyiapan memiliki perilaku akses tersendiri.

Uji versi lingkungan yang benar-benar Anda gunakan. Lihat Menghubungkan ke layanan dan pengaturan internet versi lama.

Batasi MCP server dan minta persetujuan sebelum push Git

Izinkan hanya identitas MCP server lokal yang disetujui dalam requirements.toml. Misalnya:

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

Konfigurasikan server sebenarnya secara terpisah dalam config.toml pengguna atau default terkelola, menggunakan nama dan URL yang cocok serta autentikasi yang diwajibkan server Anda:

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

Persyaratan tersebut hanya mengizinkan server yang cocok dan tidak membuatnya. Tinjau akses dan alat milik server tersebut.

Verifikasi bahwa server yang disetujui dapat terhubung dan bahwa server dengan nama atau URL berbeda tidak diizinkan.

Tambahkan aturan perintah terkelola untuk meminta peninjauan sebelum perintah publikasi yang representatif:

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

Padukan dengan allowed_approval_policies = ["on-request"] dan allowed_approvals_reviewers = ["user"] sebagai persyaratan tingkat teratas jika peninjauan oleh manusia diwajibkan.

Tolak push pengujian dan pastikan push tersebut tidak dijalankan.

Pencocokan awalan tidak mencakup setiap wrapper, klien API, aplikasi, atau jalur publikasi alternatif.

Batasi publikasi publik dengan kontrol sumber dan DLP

Di platform kontrol sumber Anda, batasi pembuatan repositori publik dan batasi siapa yang dapat mengubah visibilitas repositori, jika didukung. Tinjau izin untuk melewati pembatasan bagi pengguna dengan hak istimewa. Periksa secara terpisah akun pribadi, cuplikan kode, organisasi eksternal, dan akses token: pengaturan organisasi tidak mengatur setiap tujuan.

Di repositori terkait, wajibkan perubahan yang telah ditinjau serta tinjau perlindungan branch dan izin untuk melewati pembatasan.

Di konsol DLP organisasi Anda, konfigurasikan kebijakan uji coba untuk konten kode sumber sensitif dan saluran unggahan atau repositori yang benar-benar dicakup produk DLP Anda; tetapkan tindakan pemblokiran dan uji dengan penanda sintetis yang tidak aktif.

Jika platform kontrol sumber mendukung kontrol sisi server, konfigurasikan dan tegakkan hook yang telah ditinjau untuk repositori yang menerima push.

Gunakan tujuan pengujian yang diotorisasi dan pastikan pemblokiran berfungsi sebelum publikasi apa pun.

Verifikasi

• Buat canary yang tidak berbahaya dan pastikan upaya membaca berkas yang ditolak gagal.

• Jika akses jaringan diaktifkan, periksa bahwa tujuan yang disetujui berhasil diakses dan tujuan yang tidak disetujui diblokir; jika tidak, verifikasi bahwa permintaan jaringan diblokir.

• Dengan penanda yang tidak berbahaya serta akun atau tujuan pengujian sekali pakai, verifikasi bahwa upaya representatif untuk memublikasikan secara publik diblokir sebelum publikasi.

Batasan

Domain yang diizinkan tetap dapat memuat konten publik. Konfigurasikan pencarian web, aplikasi, MCP server, aktivitas browser, dan Codex Cloud secara terpisah; aturan sandbox lokal tidak mengontrolnya.

Menggunakan panduan konfigurasi berikut: Batasi profil izin dan Full Access; Izinkan hanya MCP server yang disetujui; Batasi tujuan jaringan; Lindungi rahasia dan repositori yang tidak terkait; Wajibkan persetujuan untuk perintah sensitif.

Anda ingin pembatasan yang mengatur Codex tetap berlaku saat Codex bekerja di repositori atau pengguna mengubah konfigurasi lokal.

• Distribusikan pembatasan izin, persetujuan, MCP, jaringan, dan perintah yang didukung sebagai persyaratan yang ditegakkan administrator.

• Instal skrip hook di direktori yang dikelola administrator dan gunakan hanya hook terkelola jika hook pengguna, proyek, dan plugin harus diabaikan.

• Lindungi berkas kebijakan dan jalur distribusi konfigurasi dengan kontrol sistem operasi dan pengelolaan perangkat. Jalankan Codex tanpa hak istimewa yang diperlukan untuk mengubah perlindungan tersebut.

• Tinjau konfigurasi efektif untuk setiap klien dan lingkungan dalam cakupan.

Tegakkan profil, persetujuan, identitas server, dan perintah yang diizinkan

Gabungkan pengaturan yang telah ditinjau ke dalam requirements.toml yang dikelola administrator, alih-alih mengandalkan pengaturan pengguna atau repositori yang dapat diedit. Misalnya:

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

Contoh ini mengizinkan dua profil, mewajibkan peninjau manusia saat persetujuan diperlukan, mengizinkan identitas MCP yang cocok, dan meminta persetujuan untuk awalan perintah tertentu.

Konfigurasikan MCP server itu sendiri secara terpisah dan tambahkan pola perintah sensitif lainnya milik organisasi. Tambahkan pembatasan berkas global dan pembatasan jaringan jika diperlukan; persyaratan membatasi pengaturan yang didukung, tetapi tidak dapat menggantikan kontrol identitas, layanan, dan tujuan di luar Codex.

Daftar izin profil terkelola memerlukan Codex 0.138.0 atau versi lebih baru.

Pada klien uji coba, coba pilih profil yang tidak diizinkan, ubah pengaturan pengguna atau proyek yang dibatasi, dan gunakan identitas MCP yang tidak tercantum dalam daftar izin; verifikasi bahwa setiap tindakan ditolak atau tetap dibatasi setelah mulai ulang. Tolak persetujuan perintah pengujian dan verifikasi bahwa perintah tersebut tidak dijalankan.

Tambahkan pembatasan sistem berkas dan jaringan terkelola

Untuk menolak akses ke berkas lokal sensitif di seluruh profil yang diizinkan, tambahkan tabel berikut ke requirements.toml dan ganti contoh dengan jalur organisasi Anda:

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

Jika perintah lokal dalam sandbox memerlukan akses jaringan, tentukan profil yang mengaktifkan jaringan dan tujuan terkelola yang diizinkan secara bersamaan:

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"

Pilih kebijakan profil ini sebagai pengganti default :workspace sebelumnya, atau gabungkan kedua nama profil secara sengaja; jangan tempel kunci atau tabel duplikat. Jika perintah tidak memerlukan jaringan, biarkan jaringan dinonaktifkan.

Verifikasi jalur spesifik yang ditolak menggunakan berkas yang tidak berbahaya, serta verifikasi tujuan yang disetujui dan tidak disetujui.

Pada Windows native, gunakan juga daftar kontrol akses berkas karena pembacaan oleh subproses shell tidak dicakup oleh deny_read terkelola saja.

Jaringan perintah lokal tidak mengatur klien lain, aplikasi, konektor, atau eksekusi cloud.

Instal dan tegakkan hook yang dikelola administrator

Minta administrator menginstal program hook yang telah ditinjau di direktori yang dikelola root, seperti /etc/codex/hooks/pre_tool_use_policy.py, dan cegah pengguna Codex mengubah berkas atau direktorinya. Dalam requirements.toml, aktifkan hook dan abaikan hook pengguna, proyek, sesi, dan plugin:

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"

Persyaratan tersebut mendaftarkan hook, tetapi tidak menginstalnya. Untuk pengujian integrasi macOS lokal, simpan yang berikut sebagai pre_tool_use_policy.py dan minta administrator menginstalnya dengan perintah di bawah ini.

Hook ini hanya memblokir penanda sintetis; ganti dengan kebijakan khusus organisasi yang telah ditinjau sebelum mengandalkannya. Pastikan /usr/bin/python3 tersedia pada target dan sesuaikan jalur interpreter jika diperlukan:

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

Mulai ulang klien lokal, lalu:

• Pastikan perintah Bash yang tidak berbahaya dapat dijalankan.

• Pastikan perintah yang memuat CODEX_HOOK_TEST_DENY diblokir.

• Verifikasi bahwa kebijakan dan dependensinya tidak dapat diubah oleh pengguna Codex.

allow_managed_hooks_only melewati semua hook pengguna, proyek, sesi, dan plugin yang tidak terkelola dan dapat memengaruhi alur kerja lain.

Pencocok Bash tidak mencakup setiap alat atau masukan yang diberikan belakangan ke proses yang sudah berjalan; kesalahan, batas waktu yang terlampaui, atau respons hook dengan format tidak valid dapat memungkinkan pemanggilan alat tetap dilanjutkan.

Work yang diorkestrasi cloud menggunakan handler hook lain yang didukung. Pertahankan perlindungan OS dan layanan yang independen. Lihat Hook terkelola dan perilaku hook.

Lindungi kebijakan dan distribusinya

Pada macOS, administrator dapat menerapkan berkas persyaratan yang telah ditinjau dan digabungkan di direktori induk milik root serta mencegah pengguna Codex menulis ke berkas tersebut:

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

Pada Linux, gunakan grup administrator yang sesuai; pada Windows, lindungi direktori ProgramData dan berkasnya dengan daftar kontrol akses yang dikelola administrator. Batasi siapa yang dapat mengubah kebijakan MDM atau cloud, tinjau perubahan, dan simpan salinan untuk pemulihan.

Dengan akun uji coba nonadministrator, verifikasi bahwa akun tersebut tidak dapat mengubah kebijakan, direktori induk, atau program hook terkelola; coba pengaturan pengguna atau proyek yang lebih longgar, mulai ulang Codex, dan verifikasi bahwa perilaku yang ditegakkan tetap berlaku.

Uji setiap klien dan lingkungan dalam cakupan, alih-alih menganggap semua klien memuat kebijakan yang sama.

Verifikasi

Dengan identitas pengujian nonadministrator:

• Coba edit kebijakan terkelola. Hasil yang diharapkan: Berkas terkelola tidak dapat diubah.

• Coba longgarkan pembatasan melalui konfigurasi pengguna atau proyek. Hasil yang diharapkan: Pengaturan yang lebih longgar ditolak atau tetap dibatasi.

• Mulai ulang klien dan verifikasi bahwa pembatasan masih berlaku.

Batasan

Pengguna atau agen dengan hak administrator host yang memadai mungkin dapat mengubah perlindungan di sekitarnya. Pengaturan yang dapat diedit pengguna saja tidak dapat menggantikan persyaratan yang dikelola administrator.