I legami tra Amazon e Anthropic affrontano la prova di OpenAI mentre AWS Continuum si espande

I legami tra Amazon e Anthropic sono entrati in una nuova fase, poiché secondo quanto riportato AWS ha collegato Continuum con Claude Code e OpenAI Codex, nonostante gli agenti di coding siano concorrenti diretti. La mossa colloca un livello di sicurezza indipendente all'interno di strumenti in grado di generare, modificare ed eseguire codice. Mette inoltre alla prova la capacità di AWS di rimanere neutrale rispetto ai modelli, mentre Amazon mantiene una stretta relazione commerciale con Anthropic.

La connessione con Codex riportata non ha ricevuto la stessa documentazione pubblica dettagliata del supporto AWS per Claude Code e per il suo ambiente Kiro. I materiali pubblicati da AWS descrivono chiaramente l'integrazione con Claude Code, la convalida simulata degli exploit e il supporto per diverse piattaforme di hosting del codice. Questa lacuna nella verifica conta, perché l'affermazione strategica più ampia dipende dalla capacità di Continuum di funzionare in ambienti di agenti concorrenti.

Non si tratta dell'ennesimo scanner aggiunto verso la fine di una pipeline di sviluppo. AWS vuole che Continuum segua le vulnerabilità dalla scoperta fino alla convalida, alla definizione delle priorità e alla correzione. Se questo approccio funziona, gli agenti di coding produrranno modifiche mentre un agente separato valuterà se tali modifiche creano rischi sfruttabili.

AWS Continuum porta la sicurezza nella sessione di coding

AWS sta spostando la revisione della sicurezza da un controllo separato allo spazio di lavoro in cui un agente AI scrive e modifica il codice.

AWS ha introdotto Continuum per le vulnerabilità del codice al suo summit di New York il 17 giugno 2026. Il servizio è entrato in anteprima limitata con un flusso di lavoro continuo che copre scoperta, definizione delle priorità, convalida, mitigazione e correzione.

L'azienda descrive Continuum come indipendente dai modelli. Ciò significa che può assegnare diversi compiti di sicurezza a diversi modelli di frontiera e incorporare nuovi modelli man mano che diventano disponibili. Il design evita di vincolare l'intero processo di sicurezza a un unico fornitore di modelli.

AWS ha inoltre integrato nella famiglia Continuum le funzionalità di AWS Security Agent. Tali funzionalità includono scansione del codice, penetration testing e threat modeling, che trasforma il codice sorgente o i documenti di progettazione in un modello strutturato dei possibili attacchi.

L'integrazione per sviluppatori documentata più chiaramente è Claude Code. AWS afferma che gli sviluppatori possono avviare attività di sicurezza dal proprio ambiente di coding anziché passare a una console di sicurezza separata. Possono creare modelli di minaccia, analizzare repository e affrontare le segnalazioni convalidate all'interno di quel flusso di lavoro.

Il plugin Claude Code funziona anche con sistemi di controllo del codice sorgente e strumenti di collaborazione. AWS ha elencato GitLab.com, GitLab autogestito, GitHub Enterprise, Bitbucket e Confluence tra le integrazioni supportate.

L'ambiente Kiro di AWS riceve un trattamento simile tramite un Kiro Power, un'estensione che concede a un agente AI l'accesso a capacità specializzate. Entrambe le integrazioni avvicinano il feedback sulla sicurezza al momento in cui un agente propone una modifica al codice.

Il rapporto di VentureBeat di agosto estende questa strategia a OpenAI Codex. Tuttavia, i materiali di rilascio AWS di giugno esaminati per questa analisi citano Kiro e Claude Code, non un plugin Codex comparabile. AWS potrebbe distribuire la connessione con Codex separatamente o attraverso un livello di integrazione più recente.

Questa distinzione non invalida il cambiamento più ampio. Definisce il confine tra ciò che AWS ha documentato pubblicamente e ciò che è stato riportato. Gli acquirenti aziendali dovrebbero richiedere documentazione del prodotto prima di presumere una parità di funzionalità tra tutti e tre gli ambienti di coding.

Il cambiamento immediato rimane comunque sostanziale. Continuum è progettato per osservare più di un frammento di codice isolato. Si basa su infrastruttura, autorizzazioni, topologia di rete, documentazione, comunicazioni e priorità aziendali per valutare se una segnalazione rappresenti un rischio significativo.

Questo contesto più ampio crea la tensione centrale dell'articolo. AWS vuole che gli sviluppatori procedano rapidamente con qualunque agente di coding preferiscano, rendendo al contempo AWS l'autorità di sicurezza che decide quali modifiche meritino fiducia.

Perché i legami tra Amazon e Anthropic non producono uno stack esclusivo

La sorpresa strategica è che AWS trae vantaggio quando Claude Code vince, ma Continuum diventa più prezioso quando supporta i rivali di Claude Code.

Amazon ha investito massicciamente in Anthropic e ha reso Claude una parte centrale della propria offerta di AI generativa. Anthropic fa inoltre affidamento sull'infrastruttura AWS, mentre i modelli Claude restano opzioni di rilievo all'interno di Amazon Bedrock.

Questa relazione conferisce ad Amazon un interesse diretto nella crescita di Anthropic. Claude Code è diventato un importante punto di accesso per gli sviluppatori che usano Claude, soprattutto per attività sull'intero repository che richiedono pianificazione, modifica, test ed esecuzione ripetuta di comandi.

Un prodotto di sicurezza AWS limitato a Claude Code rafforzerebbe questa partnership. Ridurrebbe però anche il mercato indirizzabile di Continuum e renderebbe il servizio meno utile alle imprese che operano in ambienti di sviluppo misti.

La maggior parte delle grandi organizzazioni non standardizza tutti gli sviluppatori su un unico agente di coding. I team valutano i modelli in base a linguaggio, repository, livello di rischio, disponibilità e politica interna. Alcuni sviluppatori sottopongono inoltre la stessa modifica a più agenti per l'implementazione e la revisione.

AWS ha quindi un incentivo di piattaforma diverso dall'incentivo di investimento di Amazon. Il business della piattaforma beneficia quando carichi di lavoro, contesto di sicurezza e attività di correzione transitano attraverso AWS, indipendentemente dal modello che ha scritto il codice.

Questo spiega perché OpenAI Codex rientri nella strategia. Codex compete con Claude Code nell'interfaccia per sviluppatori, ma i suoi utenti rappresentano un'altra fonte di repository, segnalazioni e decisioni di sicurezza per Continuum.

Il risultato è un modello familiare nel cloud. Un fornitore supporta software concorrenti al di sopra della propria infrastruttura perché la scelta del cliente aumenta il consumo dei servizi di livello inferiore del fornitore.

Questo modello non rende irrilevante la relazione tra Amazon e Anthropic. La ricerca di Anthropic sulla sicurezza ha contribuito a stabilire l'urgenza alla base della scoperta delle vulnerabilità fondata sul ragionamento. AWS ha citato specificamente modelli di sicurezza specializzati, incluso Claude Mythos, nello spiegare perché le operazioni di sicurezza tradizionali non riescono a tenere il passo.

Claude Mythos viene presentato come un modello specializzato nel ragionamento di cybersecurity. Secondo AWS, i modelli di questa categoria possono individuare vulnerabilità e ragionare attraverso percorsi di attacco complessi più velocemente di quanto i team tradizionali riescano a gestire l'arretrato risultante.

Questo crea una pressione su due fronti. Modelli migliori aiutano i difensori a individuare i difetti, ma gli aggressori possono usare capacità simili per trovare e sfruttare tali difetti. Ogni miglioramento nella scoperta automatizzata aumenta il valore di una convalida e di una correzione rapide.

OpenAI sta perseguendo la stessa opportunità attraverso Codex Security. VentureBeat ha riportato che la beta di OpenAI ha analizzato più di 1,2 milioni di commit e fatto emergere migliaia di segnalazioni a vari livelli di gravità. Queste cifre restano risultati riportati dall'azienda, non un confronto indipendente.

Anthropic ha inoltre promosso Claude Code Security come alternativa basata sul ragionamento all'analisi statica orientata ai pattern. Il suo lancio ha fatto seguito a una ricerca che, secondo Anthropic, ha individuato centinaia di vulnerabilità ad alta gravità in progetti open source consolidati.

AWS non sta scegliendo tra queste narrazioni sulla sicurezza. Sta posizionando Continuum al di sopra di esse. I modelli di coding possono competere su chi individua o corregge le falle più difficili, mentre AWS gestisce contesto, convalida, controlli e flusso di lavoro aziendale.

La strategia Amazon-Anthropic incontra un livello di sicurezza neutrale rispetto ai modelli

Il meccanismo più importante di Continuum non è la scoperta delle vulnerabilità, ma la separazione tra generazione del codice e giudizio sulla sicurezza.

Gli agenti di coding occupano una posizione insolita nel processo di sviluppo. Possono leggere repository, richiamare strumenti, modificare file, eseguire test, aprire pull request e talvolta interagire con sistemi di distribuzione.

Questo accesso li rende produttivi. Trasforma però anche le loro credenziali e autorizzazioni di esecuzione in obiettivi di sicurezza.

VentureBeat ha documentato diversi incidenti che coinvolgevano agenti di coding in cui gli aggressori prendevano di mira credenziali o percorsi di esecuzione anziché i pesi del modello. Un input malevolo non doveva sconfiggere l'intelligenza del modello. Doveva soltanto manipolare il modo in cui l'agente utilizzava i propri strumenti autorizzati.

Una vulnerabilità Codex riportata riguardava la gestione non sicura di un nome di branch Git appositamente creato. I ricercatori hanno mostrato come il valore potesse raggiungere uno script di configurazione ed esporre un token OAuth. Secondo quanto riportato, OpenAI ha classificato il problema con la massima priorità interna e ha distribuito una correzione.

Claude Code è stato oggetto di un esame separato riguardo ai contenuti dei pacchetti e al comportamento di comando e controllo. Questi incidenti avevano cause tecniche diverse, ma hanno esposto lo stesso problema architetturale. Un agente può diventare una superficie di attacco quando dispone di credenziali e agisce oltre una finestra di chat passiva.

Gli exploit degli agenti di coding mettono inoltre in discussione il monitoraggio tradizionale delle identità. Un token valido può autenticare l'azione di un agente anche quando la richiesta sottostante è stata manipolata da contenuti non affidabili del repository.

Continuum tenta di affrontare una parte diversa di questo rischio. Valuta le vulnerabilità del codice usando il contesto ambientale e aziendale, quindi convalida i sospetti exploit all'interno di una sandbox isolata.

Una sandbox è un ambiente contenuto in cui codice potenzialmente pericoloso può essere eseguito senza ricevere il normale accesso alla produzione. AWS afferma che Continuum utilizza questo ambiente per produrre prove riproducibili che una vulnerabilità segnalata sia sfruttabile.

Questo passaggio è importante perché i sistemi di scansione del codice spesso generano segnalazioni che non rappresentano rischi raggiungibili in produzione. Un componente vulnerabile potrebbe non essere mai eseguito, non accettare input esterni o non trovarsi su un percorso verso dati sensibili.

Il processo di definizione delle priorità di Continuum considera se un componente interessato sia distribuito, raggiungibile e connesso alla produzione. Valuta inoltre il possibile impatto aziendale prima di classificare il lavoro di correzione.

Il sistema valuta poi le protezioni esistenti, come controlli di rete, policy e meccanismi di rilevamento. Per le segnalazioni convalidate, può raccomandare una patch al codice, una modifica delle policy o una modifica della rete.

AWS afferma che le patch suggerite passano attraverso lo stesso meccanismo di convalida usato per confermare il problema originale. Il sistema può anche mostrare l'impatto previsto e un percorso di rollback quando tali dettagli sono disponibili.

Questo ciclo offre ad AWS un motivo per integrarsi sia con Claude Code sia con Codex. Il modello che scrive una patch non deve essere l'unica autorità nel decidere se la patch sia sicura.

Un team potrebbe lasciare che Claude Code crei una funzionalità, chiedere a Continuum di testare il percorso di attacco risultante e usare un altro modello durante la correzione. Lo stesso processo può applicarsi quando Codex produce la modifica iniziale.

Questa architettura limita inoltre la dipendenza da un singolo fornitore di modelli. Se un modello specializzato diventa più efficace nella costruzione di exploit o nella revisione delle patch, AWS può aggiungerlo senza sostituire l'agente di coding preferito dallo sviluppatore.

Per la partnership tra Amazon e Anthropic, la neutralità rispetto ai modelli è al tempo stesso un vantaggio e un vincolo. Claude può contribuire con un ragionamento specializzato, ma AWS mantiene il controllo su orchestrazione, policy, cronologia di audit e contesto cloud circostante.

La promessa di sicurezza dipende dal contesto e dal controllo

Continuum scambia parte dell'autonomia degli sviluppatori con un sistema di sicurezza centralizzato in grado di vedere più contesto e, in prospettiva, di intraprendere più azioni.

AWS sostiene che il modello delle operazioni di sicurezza usato nel decennio precedente stia rimanendo indietro. Quel modello raccoglie telemetria, la archivia, costruisce query e presenta avvisi tramite dashboard per la revisione umana.

Continuum collega invece la telemetria a contesto, ragionamento e azione. La differenza è importante perché un'altra dashboard aggiungerebbe solo risultati a una coda già affollata.

Il servizio opera attraverso quattro fasi continue. Innanzitutto, acquisisce gli arretrati esistenti delle vulnerabilità ed esegue le proprie scansioni. In secondo luogo, classifica i risultati usando la raggiungibilità tecnica e il contesto aziendale.

In terzo luogo, Continuum tenta di riprodurre un exploit in una sandbox. In quarto luogo, raccomanda o esegue mitigazioni tramite modifiche al codice, alla rete o alle policy.

L'architettura di Continuum inizia in una modalità di apprendimento controllata dagli esseri umani. Le raccomandazioni includono una spiegazione del ragionamento del sistema, consentendo ai team di esaminare le decisioni prima di concedere un'autorità più ampia.

Successivamente, le organizzazioni possono spostare categorie di rischio selezionate nella modalità di applicazione. In tale modalità, Continuum può applicare una correzione più automatizzata entro i limiti definiti dal cliente.

Questo design graduale affronta una preoccupazione centrale delle imprese. I responsabili della sicurezza raramente vogliono che un nuovo agente apporti modifiche senza restrizioni ai sistemi di produzione fin dal primo giorno.

L'auditabilità diventa essenziale con l'aumentare dell'autorità. AWS afferma che ogni decisione è spiegabile e ogni azione è verificabile. Afferma inoltre che gli utenti possono vedere perché Continuum ha raccomandato un'azione e cosa farebbe un rollback.

Si tratta di affermazioni dell'azienda, e la preview limitata fornisce poche prove pubbliche delle prestazioni in ambienti di produzione eterogenei. Gli acquirenti dovrebbero esaminare la qualità delle spiegazioni, non soltanto verificare se l'interfaccia le genera.

Una spiegazione leggibile può comunque omettere un'assunzione critica. Un'azione verificabile può comunque basarsi su un contesto incompleto. Un piano di rollback può fallire quando una modifica interessa servizi distribuiti o dati persistenti.

La qualità del contesto presenta un altro problema. Continuum può ragionare su codice sorgente, autorizzazioni, topologia, documenti, comunicazioni e priorità soltanto quando questi input sono accurati e accessibili.

Gli inventari dell'infrastruttura divergono dalla realtà. La documentazione diventa obsoleta. I grafi delle autorizzazioni contengono eccezioni. Le priorità aziendali possono entrare in conflitto tra team, soprattutto durante gli incidenti.

Centralizzare questi input può migliorare le decisioni di sicurezza, ma aumenta anche la sensibilità del sistema che opera su di essi. I controlli di accesso devono impedire che un repository o un team esponga informazioni appartenenti a un altro.

I team di sviluppo devono inoltre capire quando il contenuto dei repository può influenzare l'agente di sicurezza. Modelli di minaccia, commenti, documentazione e descrizioni dei problemi possono contenere testo non attendibile. I sistemi agentici devono impedire che quel testo modifichi silenziosamente la policy di sicurezza o il comportamento degli strumenti.

Queste preoccupazioni non sono argomenti contro la sicurezza agentica. Spiegano perché l'applicazione dovrebbe seguire una convalida misurata, anziché la fiducia nel marketing.

I team che valutano Continuum dovrebbero confrontare le sue decisioni con i test di penetrazione esistenti e le revisioni manuali. Dovrebbero misurare risultati confermati, falsi positivi, problemi mancati, qualità della correzione, successo del rollback e tempo risparmiato durante il triage.

Un'utile base di conoscenza ingegneristica può anche supportare la revisione umana. I team hanno bisogno di record ricercabili che colleghino i risultati alle decisioni architetturali, alla responsabilità, agli incidenti passati e ai rischi accettati.

Il vero test è se Continuum migliora queste decisioni senza nasconderle dietro un'interfaccia agente. Una correzione più rapida ha un valore limitato se i team non riescono a ricostruire perché è avvenuta una modifica in produzione.

Claude Code, Codex e gli scanner tradizionali restano in competizione

AWS Continuum entra in un mercato in cui fornitori di modelli, vendor di sicurezza e piattaforme cloud vogliono tutti possedere la stessa decisione di correzione.

I tradizionali test statici di sicurezza delle applicazioni, comunemente chiamati SAST, cercano nel codice sorgente pattern rischiosi e classi di difetti note. Funzionano senza eseguire l'applicazione e si adattano alle pipeline di sviluppo consolidate.

I modelli di ragionamento affrontano il problema in modo diverso. Possono tracciare il flusso dei dati tra i file, inferire l'intento degli sviluppatori, collegare più debolezze e valutare se una sequenza di azioni crei un percorso sfruttabile.

Anthropic e OpenAI hanno entrambe sostenuto che gli scanner basati sul ragionamento possano rilevare vulnerabilità che i sistemi basati su pattern non individuano. I loro lanci hanno aumentato la pressione sui vendor affermati della sicurezza applicativa affinché aggiungano analisi contestuali più approfondite.

Il confronto non è una semplice storia di sostituzione. Gli scanner tradizionali offrono regole deterministiche, controlli delle policy maturi, ampio supporto linguistico e report di conformità familiari. Il loro comportamento può essere più facile da riprodurre in scansioni ripetute.

I sistemi basati su modelli possono esaminare relazioni più ambigue, ma i loro output possono variare. Richiedono inoltre una gestione accurata del codice sorgente proprietario, dei prompt, degli strumenti di esecuzione e delle prove di exploit generate.

I test indipendenti hanno già rilevato dei limiti. I ricercatori di Checkmarx hanno riferito che vulnerabilità moderatamente complesse talvolta sfuggivano a Claude Code Security durante la valutazione. Tale risultato non stabilisce una classifica universale, ma mette in discussione le affermazioni secondo cui il ragionamento elimina i punti ciechi degli scanner.

Il confronto tra scanner mostra anche perché le imprese manterranno più controlli. Un agente di ragionamento può integrare la scansione deterministica, l'analisi delle dipendenze, i test e la revisione manuale invece di sostituirli immediatamente.

Continuum aggiunge un ulteriore livello competitivo perché non si limita a eseguire scansioni. Combina i risultati con il contesto dell'ambiente AWS e poi gestisce il percorso verso la correzione.

Ciò può mettere sotto pressione i vendor di sicurezza indipendenti quando i clienti gestiscono già gran parte della propria infrastruttura su AWS. Il provider cloud può accedere a relazioni di configurazione che uno strumento esterno potrebbe richiedere ai clienti di esportare o ricostruire.

I vendor indipendenti mantengono vantaggi importanti. Possono supportare più cloud senza favorire un singolo ambiente. Possono anche fornire una valutazione neutrale quando un provider cloud sta valutando i rischi all'interno dei propri servizi.

OpenAI e Anthropic affrontano una scelta correlata. Possono approfondire i loro prodotti di sicurezza nativi, integrarsi con livelli di orchestrazione esterni oppure perseguire entrambe le strategie.

Claude Code Security offre ad Anthropic un rapporto diretto con sviluppatori e team di sicurezza. Un'integrazione con Continuum amplia la portata enterprise di Claude Code, ma consente anche ad AWS di possedere la cronologia delle policy e delle correzioni.

Codex Security crea la stessa tensione per OpenAI. L'integrazione può rendere Codex più facile da approvare nelle organizzazioni incentrate su AWS. Può anche ridurre il controllo di OpenAI sul workflow di sicurezza che circonda il suo agente.

La posizione neutrale rispetto ai modelli di AWS funziona solo se i clienti si fidano che tratti tali strumenti in modo coerente. Lacune funzionali tra Kiro, Claude Code e Codex indebolirebbero quella promessa.

I dettagli pubblici mancanti sull'integrazione con Codex riportata meritano quindi attenzione. Gli acquirenti dovrebbero verificare se Codex supporta le stesse funzioni di modellazione delle minacce, scansione, convalida degli exploit e correzione documentate per Claude Code.

Dovrebbero inoltre chiedere dove viene eseguita ciascuna attività, quale modello riceve il contenuto del repository, per quanto tempo gli artefatti restano archiviati e se i risultati migliorano i modelli di qualche provider.

I legami tra Amazon e Anthropic rendono queste domande più significative. AWS deve dimostrare che il suo stretto rapporto con un'azienda di modelli non trasformi la neutralità dei modelli in una semplice affermazione di branding.

Tre segnali mostreranno se AWS può guadagnarsi la fiducia degli sviluppatori

La prossima fase dipende dalla parità di integrazione, dalla convalida indipendente e dalle prove che i clienti concederanno a Continuum un'autorità significativa.

Il primo segnale è una documentazione tecnica completa per la connessione con OpenAI Codex riportata. AWS dovrebbe identificare ambienti supportati, azioni disponibili, autorizzazioni richieste, copertura regionale e differenze rispetto a Claude Code o Kiro.

Una documentazione equivalente rafforzerebbe la tesi della neutralità rispetto ai modelli. Un connettore Codex più limitato mostrerebbe che Continuum funziona ancora meglio all'interno dell'orbita Amazon Anthropic.

Il secondo segnale è costituito da test indipendenti della convalida simulata. I ricercatori di sicurezza devono confrontare le prove di exploit di Continuum con test di penetrazione manuali su applicazioni realistiche.

Risultati solidi includerebbero alti tassi di riproduzione per risultati validi e una riduzione misurabile dei falsi positivi. I ricercatori dovrebbero anche verificare se i tentativi di exploit generati introducano rischi nella sandbox o facciano trapelare contesto sensibile.

Risultati deboli non renderebbero l'architettura irrilevante. Manterrebbero Continuum in un ruolo consultivo e rallenterebbero il passaggio dalla modalità di apprendimento alla modalità di applicazione.

Il terzo segnale è il comportamento dei clienti durante la preview limitata. AWS afferma di aver lavorato con organizzazioni nei servizi finanziari, nel settore automobilistico e nella tecnologia durante la definizione del prodotto.

Distribuzioni nominate, risultati misurati e storie operative più lunghe avrebbero più peso delle dimostrazioni di lancio. La metrica più rivelatrice sarà quanta autorità di correzione i clienti concederanno effettivamente al servizio.

I team che mantengono Continuum limitato alle raccomandazioni ricevono comunque valore dalla prioritizzazione e dalla convalida. Tuttavia, tale comportamento mostrerebbe che la fiducia non ha ancora raggiunto la visione di AWS delle azioni automatizzate.

Il passaggio alla modalità di applicazione fornirebbe prove più solide. Gli acquirenti dovrebbero comunque esaminare l'ambito consentito, perché automatizzare aggiornamenti di dipendenze a basso rischio è molto diverso dal modificare una policy di rete o il codice di produzione.

Il più ampio lancio della sicurezza agentica collega Continuum ad AWS Context, DevOps Agent, Kiro, Transform e Bedrock AgentCore. Insieme, questi servizi delineano un ciclo di vita del software sempre più gestito da agenti.

Un agente può scrivere codice. Un altro può valutare la preparazione al rilascio. Un altro può modernizzare dipendenze obsolete. Continuum può valutare le vulnerabilità e raccomandare modifiche nell'intero stack.

Questa divisione del lavoro potrebbe ridurre la dipendenza da un singolo modello di coding. Potrebbe anche rendere AWS il piano di controllo che collega agenti di aziende altrimenti in intensa competizione.

Gli sviluppatori dovrebbero porsi una domanda pratica prima di adottare questa visione: quale agente è autorizzato a giudicare il lavoro di un altro agente e quali prove supportano tale autorità?

I responsabili della sicurezza dovrebbero definire la risposta tramite autorizzazioni, dati di valutazione e workflow reversibili. Non dovrebbero fare affidamento sul fatto che ogni strumento porti il nome di un vendor familiare.

La partnership tra Amazon e Anthropic offre ad AWS accesso a modelli importanti e a una piattaforma per sviluppatori in rapida crescita. Il supporto a OpenAI Codex dimostrerebbe che AWS desidera un ruolo più ampio della distribuzione di Claude.

Nei prossimi mesi, osservate la documentazione, i test indipendenti sugli exploit e l'adozione della modalità di applicazione. Questi segnali riveleranno se Continuum diventerà un livello di sicurezza affidabile o resterà una preview ambiziosa.

Se il vostro team usa Claude Code, Codex o Kiro, mappate ora ogni credenziale e azione di produzione disponibile per questi agenti. Poi decidete dove un passaggio di convalida indipendente debba interrompere il workflow. Questo esercizio offre valore immediato, anche prima che Continuum raggiunga un'ampia disponibilità.