OpenAI Codex su Amazon Bedrock: AWS spiega come controllare accessi, costi e sicurezza

📌 In Sintesi

• AWS pubblica una guida per distribuire Codex nelle aziende. Il documento dell’11 novembre 2026 spiega come integrare l’agente di programmazione OpenAI con identità, autorizzazioni e sistemi di monitoraggio Amazon.
• I modelli vengono interrogati attraverso Amazon Bedrock. Codex continua a funzionare sul computer dello sviluppatore, mentre le richieste di inferenza seguono il percorso e i controlli configurati su AWS.
• Il controllo aziendale non elimina tutti i rischi. Servono verifiche su costi, permessi, Regioni e dati trasmessi; alcune funzionalità cloud di Codex non sono disponibili con Bedrock.

OpenAI Codex entra in una nuova fase di integrazione nelle infrastrutture aziendali AWS, dove l’intelligenza artificiale non deve soltanto scrivere codice, ma rispettare autorizzazioni, limiti di spesa e politiche di sicurezza. Amazon Web Services ha pubblicato l’11 novembre 2026 una guida tecnica che illustra come utilizzare Codex attraverso Amazon Bedrock, mantenendo l’esecuzione dell’agente sul computer dello sviluppatore e trasferendo al cloud AWS le richieste indirizzate ai modelli OpenAI. Non si tratta del lancio di un nuovo prodotto: Codex è generalmente disponibile su Bedrock dal 1° giugno 2026. La novità riguarda invece il modello operativo proposto alle organizzazioni che vogliono utilizzare agenti di programmazione senza introdurre sistemi paralleli di autenticazione, controllo dei costi e gestione delle richieste.

AWS propone tre architetture per integrare Codex nelle imprese

Nel documento tecnico pubblicato da AWS, gli specialisti Shivi Bhatia, Sebastien Couturier e Sriharsha M S descrivono tre possibilità principali. La prima è Native AWS Access, che consente agli sviluppatori di autenticarsi attraverso le identità aziendali e utilizzare direttamente Bedrock con autorizzazioni IAM. La seconda impiega Amazon Bedrock AgentCore Gateway, utile quando l’organizzazione preferisce un’infrastruttura gestita per instradamento e controlli aggiuntivi. La terza prevede un LLM Gateway, già disponibile o realizzato internamente, che può applicare politiche direttamente al traffico delle richieste. AWS raccomanda di iniziare con la soluzione meno complessa capace di soddisfare i requisiti aziendali, evitando infrastrutture supplementari prive di una necessità concreta. Il percorso sviluppa la strategia con cui AWS ha portato AgentCore, Quick e Codex nei processi software enterprise, ma introduce indicazioni operative specifiche per autorizzazioni, verifiche e monitoraggio.

Leggi anche: AWS trasforma Bedrock in una piattaforma per agenti e modelli AI

Codex rimane sul computer, mentre i modelli rispondono da Bedrock

La distinzione tecnica più importante riguarda il luogo in cui vengono eseguite le attività. Codex continua a operare localmente, attraverso la CLI, l’applicazione desktop o l’estensione per Visual Studio Code. L’agente può esaminare repository, proporre modifiche, eseguire verifiche e assistere nella programmazione, ma le richieste ai modelli vengono inviate ad Amazon Bedrock anziché all’API ospitata da OpenAI. La documentazione ufficiale OpenAI conferma che l’API Responses di OpenAI non appartiene al percorso delle richieste in questa configurazione. Per i responsabili IT questo significa poter applicare le autorizzazioni dell’account AWS e utilizzare gli strumenti di osservabilità previsti dal servizio. Non significa, invece, che tutto il codice rimanga necessariamente sul computer: prompt, contesto e informazioni necessarie all’inferenza raggiungono Bedrock. La valutazione delle informazioni trasmesse rimane quindi un requisito essenziale prima di adottare il sistema in ambienti regolamentati.

IAM, modelli supportati e configurazione degli sviluppatori

La guida consiglia di partire con un progetto pilota a privilegi minimi, utilizzando identità aziendali e accessi verificabili. OpenAI documenta il supporto per GPT-5.6 Sol, Terra e Luna, oltre a GPT-5.5 e GPT-5.4, purché disponibili nella Regione AWS selezionata. L’esempio Amazon utilizza GPT-5.6 Sol e configura il provider amazon-bedrock nel file locale ~/.codex/config.toml. L’autenticazione può sfruttare credenziali AWS gestite attraverso IAM e Identity Center oppure chiavi API Bedrock. La guida ufficiale di configurazione OpenAI richiede almeno Codex CLI 0.128.0 oppure le versioni compatibili dell’applicazione desktop e dell’estensione IDE. Prima di distribuire il sistema a un intero reparto, AWS suggerisce di verificare l’identità effettivamente utilizzata, il modello autorizzato, la Regione di elaborazione e la possibilità di revocare rapidamente l’accesso.

CloudWatch misura l’utilizzo, ma non garantisce il controllo della spesa

La parte economica assume un ruolo centrale. AWS propone l’utilizzo di OpenTelemetry, attraverso AWS Distro for OpenTelemetry, e delle dashboard Amazon CloudWatch per osservare richieste, token utilizzati, durata delle operazioni e attività dei client. Tuttavia, misurare il consumo di token non equivale a ricostruire automaticamente la fattura di ogni sviluppatore. L’attribuzione richiede la correlazione tra identità, registrazioni delle richieste e dati contabili AWS. Il documento distingue inoltre il monitoraggio dagli strumenti capaci di bloccare effettivamente un’operazione: un allarme sui consumi non rappresenta necessariamente un limite vincolante alla spesa. Per imporre controlli direttamente sul percorso delle richieste può essere necessario un gateway dedicato. È una differenza significativa rispetto ai sistemi di tetto massimo esaminati nell’analisi dei controlli di spesa di Google Cloud e delle quote OpenAI. La guida non introduce un nuovo listino Codex: prezzi, quote e disponibilità devono essere verificati per il servizio e l’account utilizzati.

Sicurezza e sovranità dei dati: AWS non offre una garanzia automatica

L’impiego di Bedrock permette alle aziende di scegliere infrastrutture e controlli coerenti con le proprie politiche, ma non trasforma automaticamente ogni configurazione in una soluzione di sovranità digitale. La Regione selezionata, gli eventuali profili di inferenza interregionali, le autorizzazioni e la gestione dei log determinano il trattamento effettivo delle informazioni. AWS raccomanda inoltre di escludere credenziali, segreti e dati riservati dai materiali trasmessi ai modelli, salvo esplicita autorizzazione aziendale. Le modifiche generate da Codex devono essere revisionate e sottoposte a test prima dell’integrazione nei repository. Il tema riguarda anche le imprese italiane che stanno valutando il passaggio dagli strumenti AI utilizzati individualmente agli agenti governati dall’organizzazione. La disponibilità di Codex e dei modelli OpenAI su infrastrutture cloud differenti aumenta le opzioni commerciali, ma impone verifiche indipendenti su conformità, residenza dei dati e responsabilità operative.

Quali funzioni di Codex non sono disponibili con Amazon Bedrock

La compatibilità non è completa. OpenAI precisa che la configurazione Bedrock non supporta attualmente la generazione di immagini, la trascrizione vocale per l’input, lo store dei plugin cloud e gli agenti cloud Codex, compresi quelli dedicati a revisione, sicurezza e attività web. Anche alcune capacità basate su MCP e sulla ricerca degli strumenti possono risultare limitate. Non è quindi corretto presentare Codex su AWS come una replica identica dell’esperienza disponibile attraverso i servizi OpenAI. Le organizzazioni devono scegliere quali funzionalità siano realmente necessarie prima di impostare migrazioni o procedure interne. Il precedente sviluppo di AgentCore come registro governato di agenti e strumenti mostra quanto il controllo delle integrazioni sia ormai parte integrante dell’architettura enterprise, non un semplice dettaglio di configurazione.

Continua con:

OpenAI taglia i prezzi dei modelli mentre aumentano i costi operativi dell’AI

Perché la nuova guida AWS interessa anche le aziende italiane

Il vero sviluppo dell’11 novembre riguarda il passaggio dall’utilizzo sperimentale di Codex alla sua amministrazione come servizio aziendale. La piattaforma può diventare utile quando sviluppatori, responsabili della sicurezza e uffici finanziari condividono regole verificabili su identità, modelli, consumi e informazioni trasferite all’esterno. AWS suggerisce di iniziare con pochi utenti e repository non produttivi, controllare i risultati e predisporre una procedura di revoca prima di ampliare l’accesso. Per le imprese italiane, soprattutto quelle che sviluppano software destinato a infrastrutture critiche, pubbliche amministrazioni e settori regolamentati, questa impostazione appare più rilevante della semplice disponibilità di nuovi modelli. La sfida non è soltanto far scrivere codice all’intelligenza artificiale, ma sapere chi la utilizza, quali dati le vengono affidati, quanto costa e come impedirle di superare i limiti stabiliti dall’organizzazione.