Man mano che i sistemi di IA diventano più capaci, agiscono sempre più per conto degli utenti. Gli agenti di coding possono esaminare repository in autonomia, eseguire comandi e interagire con gli strumenti di sviluppo. Si tratta di attività che prima richiedevano un intervento umano diretto.
Con Codex, abbiamo progettato queste capacità insieme ai controlli necessari alle organizzazioni per una distribuzione sicura. I team di sicurezza hanno bisogno di strumenti per governare il funzionamento degli agenti: a cosa possono accedere, quando è richiesta l’approvazione umana, con quali sistemi possono interagire e quali dati di telemetria sono disponibili per comprenderne il comportamento.
In OpenAI distribuiamo Codex con alcuni obiettivi chiari: mantenere l’agente entro confini tecnici ben definiti, consentire agli sviluppatori di agire rapidamente nelle attività a basso rischio e rendere esplicite le azioni a rischio più elevato. Manteniamo inoltre una telemetria nativa dell’agente per comprendere e verificare ciò che ha fatto. In pratica, questo significa configurazione gestita, esecuzione vincolata, policy di rete e log nativi dell’agente.
Distribuiamo Codex seguendo un principio semplice: deve essere produttivo all’interno di un ambiente delimitato, le azioni quotidiane a basso rischio devono essere fluide e quelle a rischio più elevato devono richiedere una revisione.
Approvazioni e sandboxing lavorano insieme. La sandbox definisce il confine tecnico di esecuzione, inclusi i percorsi in cui Codex può scrivere, l’accesso alla rete e quali percorsi restano protetti. La policy di approvazione stabilisce quando Codex deve chiedere il permesso per eseguire un’azione, ad esempio quando deve operare al di fuori della sandbox. Gli utenti possono approvare una singola azione oppure autorizzare quel tipo di azione per l’intera sessione.
Per le richieste che superano il limite della sandbox, utilizziamo la Modalità di revisione automatica(si apre in una nuova finestra), una funzione che, quando è attivata, approva automaticamente determinati tipi di richieste per ridurre la frequenza con cui gli utenti devono interrompersi e approvare le azioni di Codex. Codex invia l’azione pianificata e il contesto recente al subagente di approvazione automatica, che può approvare automaticamente le azioni a basso rischio o le azioni ad alto rischio con un livello sufficiente di autorizzazione dell’utente, senza interrompere l’utente. Questo consente a Codex di continuare le attività di routine, fermandosi però davanti ad azioni a rischio più elevato o con conseguenze indesiderate.
Non eseguiamo Codex con accesso in uscita illimitato. La nostra policy di rete gestita consente le destinazioni previste, blocca quelle che non vogliamo che Codex raggiunga e richiede approvazione per i domini sconosciuti. Questo permette a Codex di completare flussi di lavoro comuni e affidabili senza concedergli un accesso esteso alla rete.
Gestiamo anche il modo in cui Codex si autentica. Le credenziali OAuth di CLI e MCP sono archiviate nel portachiavi sicuro del sistema operativo, l’accesso avviene obbligatoriamente tramite ChatGPT ed è vincolato alla nostra area di lavoro enterprise di ChatGPT. Questo mantiene l’utilizzo di Codex legato ai controlli a livello di workspace e rende disponibile l’attività di Codex nella ChatGPT Compliance Logs Platform per la nostra area di lavoro Enterprise.
Utilizziamo regole affinché Codex non consideri ogni comando shell ugualmente sicuro. I comandi sicuri più comuni usati dagli ingegneri nello sviluppo quotidiano sono consentiti senza approvazione al di fuori della sandbox, mentre comandi specifici più pericolosi possono essere bloccati o richiedere approvazione. Questo permette a Codex di procedere rapidamente nelle normali attività di ingegneria, imponendo comunque una revisione o bloccando pattern che non vogliamo eseguire al di fuori della sandbox.
Applichiamo questo approccio tramite una combinazione di requisiti gestiti dal cloud, preferenze gestite di macOS e file di requisiti locali. I requisiti sono controlli imposti dagli amministratori che gli utenti non possono modificare. Le preferenze gestite di macOS e i file di requisiti locali ci consentono di mantenere una base coerente, continuando però a testare configurazioni diverse per team, gruppi di utenti o ambienti. Queste configurazioni si applicano a tutte le superfici locali di Codex, incluse l’app desktop, la CLI e l’estensione IDE.
Il controllo è solo metà del lavoro. Una volta distribuiti gli agenti, i team di sicurezza hanno bisogno di visibilità su ciò che stanno facendo e sul perché. I log di sicurezza tradizionali restano utili per analizzare le azioni eseguite da Codex, ma nella maggior parte dei casi rispondono solo a cosa è successo: è stato avviato un processo, un file è stato modificato, è stata tentata una connessione di rete. I difensori devono comunque capire perché Codex abbia fatto qualcosa o quale fosse l’intento dell’utente.
Codex può offrire ai team di sicurezza una visione più consapevole degli agenti. Supporta l’esportazione dei log OpenTelemetry per vari eventi di Codex, come prompt utente, decisioni di approvazione degli strumenti, risultati dell’esecuzione degli strumenti, utilizzo dei server MCP ed eventi di autorizzazione o blocco del proxy di rete. I log delle attività di Codex sono disponibili anche tramite la OpenAI Compliance Platform per i clienti Enterprise ed Edu.
In OpenAI utilizziamo i log di Codex insieme al nostro agente di triage della sicurezza basato sull’IA. Quando un avviso endpoint segnala che Codex ha eseguito qualcosa di insolito, lo strumento di sicurezza endpoint indica che si è verificato un evento sospetto. I log di Codex aiutano quindi a chiarire il contesto e l’intento dell’utente e dell’agente. Il nostro agente di triage della sicurezza basato sull’IA utilizza i log di Codex per analizzare la richiesta originale, l’attività degli strumenti, le decisioni di approvazione, i risultati degli strumenti ed eventuali decisioni o blocchi della policy di rete. L’agente presenta poi la propria analisi al team di sicurezza per distinguere tra comportamento previsto dell’agente, errori innocui e attività che richiedono realmente un’escalation.
Utilizziamo la stessa telemetria anche a livello operativo. Questi log ci aiutano a capire come evolve l’utilizzo interno, quali strumenti e server MCP vengono usati, con quale frequenza la sandbox di rete blocca o richiede approvazione e dove il rollout necessita ancora di ottimizzazioni. I log OpenTelemetry possono essere centralizzati nei sistemi SIEM e di compliance logging.
Man mano che agenti di coding come Codex si integrano nei flussi di lavoro di sviluppo, i team di sicurezza hanno bisogno di strumenti progettati specificamente per gestire questo cambiamento. Codex offre le superfici di controllo, la gestione della configurazione, il sandboxing e la telemetria dettagliata e orientata agli agenti necessari per garantire un utilizzo sicuro. Con queste capacità, i team di sicurezza possono abilitare Codex con maggiore fiducia, bilanciando la produttività degli sviluppatori con la visibilità e il controllo richiesti dalla sicurezza enterprise. Maggiori informazioni sulla configurazione di Codex sono disponibili qui(si apre in una nuova finestra), e sulla Compliance API qui(si apre in una nuova finestra).
