Kung paano safe na pinagagana sa OpenAI ang Codex

Habang mas nagiging capable ang mga AI system, mas nakakakilos na rin sila para sa mga user. Magagawa na mga coding agent na mag-review ng mga repository, mag-run ng mga command, at makipag-interact sa mga development tool nang sila na lang. Dati, kailangan pang direktang gawin ng tao ang mga task na ito.

Sa Codex, dinisenyo namin ang mga capability na ito at ang mga kontrol na kailangan ng mga organization para sa safe na deployment. Kailangan ng mga security team ng mga paraan para ma-manage kung paano nag-o-operate ang mga agent: kung ano ang puwedeng ma-access ng mga ito, kailan kailangan ng approval ng tao, sa aling mga system puwedeng makipag-interact ang mga ito, at anong telemetry ang dapat nag-e-exist para maipaliwanag ang behavior ng mga ito.

Sa OpenAI, dine-deploy namin ang Codex taglay ang ilang malinaw na goal: panatilihin ang agent sa loob ng malinaw na mga technical boundary, hayaang makakilos nang mabilis ang mga developer sa mga low-risk action, at malinaw na i-identify ang mga higher-risk action. Pini-preserve din namin ang built-in agent telemetry para maintindihan namin at ma-audit ang ginawa ng agent. Ibig sabihin nito, kailangang i-manage ang configuration, i-constrain ang execution, magpatupad ng mga network policy, at mag-maintain ng mga built-in agent log.

Dine-deploy namin ang Codex batay sa simpleng prinsipyo na dapat itong maging productive sa isang environment na may mga boundary, dapat maging smooth ang takbo ng mga low-risk at pang-araw-araw na action at dapat tumigil ang mga higher-risk action para ma-review.

Parehong mahalaga ang ginagawa ng mga approval at sandboxing. Ang sandbox ang nagse-set ng boundary para sa technical execution, sinasabi rin nito kung saan magsusulat ang Codex, kung maa-access nito ang network, at aling mga path ang protected. Sinasabi naman ng approval policy kung kailan dapat humingi ng permission ang Codex para gumawa ng isang action, halimbawa, kapag may kailangan itong gawin sa labas ng sandbox. Puwedeng i-approve ng mga user ang action nang isang beses, o i-approve ang ganoong action para sa ganoong session.

Para sa mga kahilingang lumalampas sa hngganan ng sandbox, ginagamit namin ang Auto-review mode⁠(magbubukas sa bagong window), isang tampok na kapag naka-on, awtomatikong inaaprubahan ang ilang uri ng kahilingan para mabawasan kung gaano kadalas kailangang huminto ng mga user at aprubahan ang mga aksyon ng Codex. Ipinapadala ng Codex ang nakaplanong aksyon at kamakailang konteksto sa auto-approval subagent, na maaaring awtomatikong aprubahan ang mga aksyong mababa ang panganib—o mga aksyong mas mataas ang panganib na may sapat na antas ng awtorisasyon ng user—sa halip na gambalain ang user. Nakakatulong ito para magtuloy-tuloy ang Codex sa nakagawiang gawain pero tumitigil pa rin sa mga aksyon na mas mataas ang panganib na may hindi sinasadyang resulta.

Hindi namin hinahayaang i-access ng Codex ang internet o mga external na network nang walang limitasyon. Dahil sa controlled o managed na network policy namin, mga inaasahan o approved na destination lang ang pinapayagan nito, bina-block nito ang mga destination na hindi namin gustong ma-access ng Codex, at nanghihingi ito ng approval para sa mga di-pamilyar na domain. Kaya natatapos ng Codex ang mga karaniwan at kilalang maayos na workflow nang hindi ito binibigyan ng malawak na access sa network.

Mina-manage din namin kung paano nag-a-authenticate ang Codex. Ang mga CLI at MCP OAuth credential ay naka-store sa secure na OS keyring, para maka-log in kailangan munang dumaan sa ChatGPT, at ang access ay naka-connect sa ChatGPT enterprise workspace namin. Dahil dito, ang paggamit sa Codex ay nananatiling naka-connect sa mga workspace-level control namin at nagiging available ang activity ng Codex sa ChatGPT Compliance Logs Platform para sa enterprise workspace namin.

Gumagamit kami ng mga rule para hindi ituring ng Codex na pare-parehong safe ang bawat shell command. Ang mga karaniwan at safe na command na ginagamit ng mga engineer sa araw-araw na pag-develop ay pinapayagan nang wala nang approval sa labas ng sandbox, at ang mga specific na mapanganib na command ay puwedeng i-block o hingan ng approval. Dahil dito, mabilis na nakakakilos ang Codex sa mga ordinaryong engineering task habang nagpapatupad pa rin ng review o mga blocking pattern na ayaw naming i-run sa labas ng sandbox.

Ini-implement namin ang approach na ito gamit ang mga cloud-managed requirement, mga macOS managed preference, at mga local requirement file. Ang mga requirement ay mga kontrol na ipinapatupad ng admin na hindi mao-override ng mga user. Nakakatulong ang managed preferences ng macOS at mga local requirements file na mapanatili ang consistent na baseline habang tini-test pa rin ang iba’t ibang configuration nang ayon sa team, user group, o environment. Ang mga configuration na ito ay inia-aaply sa lahat ng local Codex surface, kasama na ang desktop app, CLI, at IDE extension.

Marami pang dapat gawin bukod sa kontrol. Kapag na-deploy na ang mga agent, kailangang makita ng mga security team kung ano ang mga ginagawa ng mga agent na ito at bakit. Nakakatulong pa rin ang mga tradisyonal na security log kapag tinitingnan ang mga ginawang action ng Codex, pero madalas, ang nasasagot lang ng mga ito ay kung ano ang nangyari: nagsimula ang isang proseso, may nabagong file, o nag-attempt na mag-connect sa isang network. Kailangan pa ring i-figure out ng mga defender kung bakit ginawa ng Codex ang isang bagay, ao ang intensyon ng user.

Makakapagbigay ang Codex sa mga security team ng mas maraming insight tungkol sa mga ginagawa ng agent. Kayang mag-export ng Codex ng OpenTelemetry log para sa iba’t ibang Codex event na gaya ng mga user prompt, tool approval decision, tool execution result, MCP server usage, at network proxy allow or deny event. Available rin ang mga activity log ng Codex sa OpenAI Compliance Platform para sa mga customer ng Enterprise at Edu.

Sa OpenAI, ginagamit namin ang mga log ng Codex kasama ng AI-powered na security triage agent namin. Kapag may endpoint alert na nagsasabing may hindi pangkaraniwang ginawa ang Codex, sinasabi sa amin ng endpoint security tool na may suspicious event na nangyayari. Pagkatapos, nakakatulong ang mga log ng Codex na maipaliwanag ang intensyon ng user at agent. Ginagamit ng AI security triage agent namin ang mga log ng Codex para i-inspect ang original na request, activity ng tool, mga approval decision, mga tool result, at kahit anong relevant na network policy decision o block. Ipinapakita ng AI security triage agent ang analysis nito sa security team namin para ma-review at malaman kung ito ba ay inaasahang behavior ng agent, mga harmless na pagkakamali, at activity na talagang kailangang i-escalate.

Ginagamit din namin ang ganiyang telemetry sa operation. Ginagamit namin ang mga log na ito para maintindihan kung paano nagbabago ang internal na paggamit, aling mga tool at MCP server ang ginagamit, gaano kadalas gumagawa ng blocking o prompting ang network sandbox, at saan pa kailangan i-improve ang rollout. Puwedeng i-centralize ang mga OpenTelemetry log na ito sa SIEM at mga compliance logging system.

Habang ini-integrate sa mga development workflow ang mga coding agent na tulad ng Codex, kailangan ng mga security team ng mga tool na partikular na dinisenyo para ma-manage ang pagbabagong ito. Ang Codex ay naglalaan ng mga control surface, configuration management, sandboxing, at detalyadong agent-aware telemetry na kailangan para matiyak ang safe na paggamit. Dahil sa mga capability na ito, mapapagana ng mga security team ang Codex nang may higit na kumpiyansa, na binabalanse ang productivity ng developer at ang visibility at kontrol na kailangan para sa security ng enterprise. Mas marami pang impormasyon tungkol sa pag-configure ng Codex ang makikita rito⁠(magbubukas sa bagong window), at sa Compliance API dito⁠(magbubukas sa bagong window).