Home Fondamenti Token Modelli AI Deep Learning Tecniche RAG MCP Orchestrazione Prompt Engineering Usare l'AI ChipsBot News

Esecuzione sicura di Codex su OpenAI

OpenAI Blog 8 maggio 2026

La crescente capacità dei sistemi di intelligenza artificiale sta portando a una maggiore autonomia nell'esecuzione di compiti. I codici di agenti possono revisionare autonomamente i repository, eseguire comandi e interagire con strumenti di sviluppo. Questi sono compiti che in precedenza richiedevano l'esecuzione diretta da parte degli esseri umani.

Con Codex, abbiamo progettato queste capacità insieme ai controlli necessari per le organizzazioni per una distribuzione sicura. I team di sicurezza hanno bisogno di modi per governare come gli agenti operano: cosa possono accedere, quando è richiesta l'approvazione umana, con quali sistemi possono interagire e quale telemetria esiste per spiegare il loro comportamento.

Presso OpenAI, distribuiamo Codex con alcuni obiettivi chiari: mantenere l'agente all'interno di confini tecnici chiari, consentire agli sviluppatori di muoversi rapidamente su azioni a basso rischio e rendere esplicite le azioni a più alto rischio. Conserviamo anche la telemetria nativa dell'agente in modo da poter capire e verificare cosa ha fatto l'agente. In pratica, significa configurazione gestita, esecuzione vincolata, politiche di rete e log nativi dell'agente.

Controllare come opera Codex

Distribuiamo Codex con un principio semplice: dovrebbe essere produttivo all'interno di un ambiente limitato, le azioni quotidiane a basso rischio dovrebbero essere senza attrito e le azioni a più alto rischio dovrebbero essere soggette a revisione.

Le approvazioni e il sandboxing lavorano insieme. Il sandbox definisce il confine di esecuzione tecnica, compreso dove Codex può scrivere, se può raggiungere la rete e quali percorsi rimangono protetti. La politica di approvazione determina quando Codex deve chiedere di eseguire un'azione, ad esempio quando deve fare qualcosa al di fuori del sandbox. Gli utenti possono approvare l'azione una volta o approvare quel tipo di azione per quella sessione.

Per le richieste di approvazione di routine, stiamo utilizzando la modalità di revisione automatica, che è una funzione che, quando attivata, auto-approva determinati tipi di richieste per ridurre la frequenza con cui gli utenti devono interrompere 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 invece di interrompere l'utente. Ciò mantiene Codex in movimento su lavoro di routine mentre si ferma su azioni a più alto rischio o con conseguenze non intenzionali.

Non eseguiamo Codex con accesso in uscita aperto. La nostra politica di rete gestita consente destinazioni attese, blocca destinazioni che non vogliamo raggiungere con Codex e richiede l'approvazione per domini sconosciuti. Ciò consente a Codex di completare flussi di lavoro comuni e noti senza concedergli un ampio accesso alla rete.

Gestiamo anche come Codex si autentica. Le credenziali OAuth di CLI e MCP sono archiviate nell'anello delle chiavi del sistema operativo sicuro, il login è forzato tramite ChatGPT e l'accesso è bloccato sul nostro spazio di lavoro aziendale ChatGPT. Ciò mantiene l'utilizzo di Codex legato ai nostri controlli a livello di spazio di lavoro e rende l'attività di Codex disponibile nella piattaforma di log di conformità ChatGPT per il nostro spazio di lavoro aziendale.

Utilizziamo regole in modo che Codex non tratti ogni comando shell come ugualmente sicuro. I comandi comuni e innocui che gli ingegneri utilizzano nel lavoro quotidiano sono consentiti senza approvazione al di fuori del sandbox e i comandi pericolosi possono essere bloccati o richiedere l'approvazione. Ciò consente a Codex di muoversi rapidamente attraverso le attività di ingegneria ordinarie mentre ancora richiede la revisione o blocca i modelli che non vogliamo eseguire al di fuori del sandbox.

Applichiamo questa posizione attraverso una combinazione di requisiti gestiti nel cloud, preferenze gestite macOS e file di requisiti locali. I requisiti sono controlli amministrativi che gli utenti non possono sovrascrivere. Le preferenze gestite macOS e i file di requisiti locali ci consentono di mantenere una base coerente mentre testiamo diverse configurazioni per team, gruppo di utenti o ambiente. Queste configurazioni si applicano a tutte le superfici locali di Codex, comprese l'app desktop, CLI e l'estensione IDE.

Telemetria nativa dell'agente e tracce di audit

Il controllo è solo la metà del lavoro. Una volta distribuiti gli agenti, i team di sicurezza hanno bisogno di visibilità su cosa stanno facendo questi agenti e perché. I log di sicurezza tradizionali sono ancora utili quando si esaminano le azioni intraprese da Codex, ma in genere rispondono a cosa è successo: un processo è stato avviato, un file è stato modificato, una connessione di rete è stata tentata. I difensori sono ancora lasciati a capire perché Codex ha fatto qualcosa o l'intento dell'utente.

Codex può fornire ai team di sicurezza una visione più consapevole dell'agente. Codex supporta l'esportazione del log OpenTelemetry per vari eventi di Codex, come prompt dell'utente, decisioni di approvazione degli strumenti, risultati dell'esecuzione degli strumenti, utilizzo del server MCP e eventi di proxy di rete di consentire o negare. I log di attività di Codex sono anche disponibili tramite la piattaforma di conformità OpenAI per i clienti aziendali e educativi.

Presso OpenAI, utilizziamo i log di Codex insieme al nostro agente di triage di sicurezza alimentato da intelligenza artificiale. Quando un allarme di endpoint dice che Codex ha fatto qualcosa di insolito, lo strumento di sicurezza di endpoint ci dice che si è verificato un evento sospetto. I log di Codex aiutano quindi a spiegare l'intento circostante dell'utente e dell'agente. Il nostro agente di triage di sicurezza alimentato da intelligenza artificiale utilizza i log di Codex per esaminare la richiesta originale, l'attività degli strumenti, le decisioni di approvazione, i risultati degli strumenti e qualsiasi decisione di politica di rete o blocco rilevante. L'agente di triage di sicurezza presenta la sua analisi al nostro team di sicurezza per la revisione per distinguere tra il comportamento dell'agente previsto, gli errori benigni e l'attività che realmente merita un'escalation.

Utilizziamo anche la stessa operazione di telemetria. Utilizziamo questi log per capire come l'adozione interna sta cambiando, quali strumenti e server MCP vengono utilizzati, con quale frequenza il sandbox di rete sta bloccando o richiedendo l'approvazione e dove il rollout richiede ancora regolazioni. Questi log OpenTelemetry possono essere centralizzati nei sistemi di log di conformità e SIEM.

Guardando avanti

Mentre gli agenti di codifica come

Leggi l'articolo originale →
← Torna alle news