I coding agent sono ora un problema di sicurezza in produzione

OpenAI ha pubblicato in silenzio la propria postura di sicurezza interna per eseguire Codex in produzione — non un documento di marketing, ma un testo da operatore che copre sandboxing, egress di rete, gate di approvazione e telemetria nativa per agent. Per i CTO sotto pressione per distribuire coding agent questo trimestre, questa è la prima architettura di riferimento credibile prodotta da un team che la gestisce davvero su larga scala. Il gap strategico che mette in luce non è se adottare i coding agent — è se il tuo platform team ha una storia di contenimento prima che la tua organizzazione ingegneristica apra la porta.

Cosa è cambiato nel modo in cui OpenAI gestisce Codex

Il post Running Codex Safely di OpenAI descrive il layer di controllo che l'azienda opera internamente quando gli agent Codex lavorano all'interno di codebase reali. L'architettura si regge su quattro pilastri: ambienti sandbox isolati per ogni task dell'agent, restrizioni esplicite sull'egress di rete che bloccano le chiamate in uscita arbitrarie, gate di approvazione human-in-the-loop per azioni che superano una soglia di blast radius definita, e telemetria strutturata che cattura le decisioni dell'agent — non solo gli output — a fini di audit.

Il modello di sandboxing è task-scoped, non session-scoped. Ogni task di coding ottiene il proprio ambiente effimero, senza stato persistente tra un'esecuzione e l'altra. Le policy di rete sono deny di default, con allowlist gestite per progetto anziché per agent. I gate di approvazione sono a livelli: le operazioni a basso rischio (lettura, lint, test) girano in autonomia; le operazioni di scrittura sui branch principali o su file vicini ai secret richiedono l'approvazione umana prima dell'esecuzione. La telemetria è progettata per registrare il reasoning trace dell'agent insieme alle sue azioni, rendendo la revisione post-incidente gestibile anziché un'attività affidata all'intuizione.

Ciò che rende questo documento insolito è la provenienza. La maggior parte delle linee guida sui coding agent arriva dai vendor che li vendono. Qui viene descritto invece ciò che un'organizzazione ha scelto per se stessa quando l'agent lavora sui propri sistemi in produzione — una struttura di accountability materialmente diversa.

Perché questo cambia i calcoli sulla proprietà degli agent nel tuo stack

La maggior parte delle organizzazioni ingegneristiche che valutano i coding agent nel maggio 2026 li tratta come una decisione di procurement per strumenti da sviluppatore — quale plugin per l'IDE, quale modello, quale piano tariffario. Questo inquadramento manca il punto su dove cade davvero il rischio. Un coding agent con accesso in scrittura al repo, accesso alle variabili d'ambiente e la capacità di aprire pull request è un attore privilegiato nella tua catena CI/CD. Il threat model non è l'agent che "va fuori controllo"; è l'agent che fa esattamente quello che gli viene detto, da un prompt che è stato manipolato, da un allowlist mal configurata, o da un gate di approvazione che nessuno ha revisionato perché la coda si muoveva troppo in fretta.

Il punto che la maggior parte dei media manca: la telemetria per i coding agent richiede uno schema diverso da quella applicativa. Non puoi ricostruire cosa ha deciso di fare un agent dai log standard che catturano solo ciò che ha eseguito. Senza la cattura del reasoning trace — i passi intermedi dell'agent, le tool call e le alternative scartate — il tuo team di incident response legge i fondi di caffè. La postura di OpenAI integra tutto questo fin dall'inizio. La maggior parte dei platform team con cui parliamo non ne ha nulla.

Il secondo gap riguarda il design dei gate di approvazione. Un gate che scatta su ogni commit vanifica il caso produttività. Un gate che scatta solo sui deploy manca la classe di rischio che vive nei cambiamenti di dipendenze, nei riferimenti a secret e nelle modifiche ai file di test che abbassano le soglie di coverage senza innescare flag evidenti. L'approccio OpenAI stratifica per blast radius — un concetto che il tuo platform team deve operativizzare per la topologia specifica dei tuoi repo prima che gli agent vadano live, non dopo il primo incidente.

Parla con Domani AI per costruirlo →

Cosa deve fare il tuo platform team questa settimana

Il compito di questa settimana è un audit di readiness, non una decisione di rollout. Prima che qualsiasi coding agent ottenga accesso al repo — anche in un ambiente di staging — il tuo platform team ha bisogno di risposte a tre domande che si ramificano diversamente a seconda della sensibilità dei repo e dell'organico della tua organizzazione.

Segui questo albero decisionale:

• Alcuni dei repo che l'agent andrebbe a toccare contengono secret, credenziali o config di ambiente? Se sì: i controlli sull'egress di rete e la secrets-scanning nel sandbox sono precondizioni non negoziabili, non elementi di una fase successiva.
• La tua pipeline CI/CD si attiva automaticamente alla creazione di una PR? Se sì: hai bisogno di gate di approvazione prima della creazione della PR, non solo prima del merge. Le pipeline automatizzate comprimono la finestra tra l'azione dell'agent e l'effetto in produzione.
• Riesci a ricostruire cosa ha deciso l'agent — non solo cosa ha fatto — dal tuo setup di logging attuale? Se no: strumenta la cattura del reasoning trace prima di andare live. Il tuo security team ne avrà bisogno la prima volta che qualcosa di inatteso finisce in produzione.

Per i team sotto i 150 ingegneri: parti da un singolo repo a bassa sensibilità, policy di rete deny-by-default e revisione umana obbligatoria su tutte le scritture. Espandi lo scope di accesso solo dopo aver accumulato 4 settimane di telemetria che riesci davvero a leggere. Per i team sopra i 150: la coda dei gate di approvazione diventerà un collo di bottiglia più in fretta del previsto — progetta la logica di tiering adesso, non quando gli ingegneri inizieranno a bypassare il gate perché blocca il loro sprint.

Quanto costa — e quanto costa saltarlo

Costruire un layer di controllo sandbox-più-telemetria per i coding agent è un investimento di piattaforma da 3–6 settimane per un team di 2 senior engineer, assumendo che tu non parta da zero sull'infrastruttura di ambienti effimeri. Se stai già operando ambienti CI task-scoped, il lavoro incrementale si avvicina alle 2 settimane. La logica dei gate di approvazione — in particolare il tiering per blast radius — è dove va il tempo di design, non nella parte di tooling.

Il costo di saltarlo è difficile da stimare in anticipo ed è molto facile da calcolare a posteriori. Un singolo incidente in cui un agent fa il commit di una dipendenza con una CVE nota, espone un riferimento a un secret in una PR, o degrada la test coverage su un servizio critico costerà più in remediation e in ricostruzione della fiducia di quanto non costi costruire la piattaforma. In termini pratici: se la tua organizzazione ingegneristica sente già la pressione di distribuire l'accesso ai coding agent, la via di minor resistenza è aprirlo senza controlli e fare patch dopo. Quella strada ha una storia, e non finisce bene. La postura di OpenAI esiste perché hanno scelto di fare questo lavoro prima che gli incidenti li costringessero a farlo. Questa è la scelta sul tavolo questa settimana.